New Pull Request Builder
#11
Usually x86 executables pack better than 1/2 of the original size, with UPX the ratio can be even higher, even 1/4 of the original size. And individually-compressed builds should be okay.
Reply
Thanks given by:
#12
Had another look and this may not be feasible. Uploading the files is doable if you know what to upload them as. The problem is that travis builds do not appear to know if they are triggered as the result of a pull request so we don't know what to upload the file as and where to post the link.

Alternate option: implement https://github.com/travis-ci/travis-ci/issues/532 so that we don't have to do this in such a hacky way.
Reply
Thanks given by:
#13
No, me being stupid and looking in the wrong place in the manual, its TRAVIS_PULL_REQUEST. derp.
Reply
Thanks given by:
#14
So apart from ftp config I should be able to set up to store the artefacts and post the comment on build success.
Reply
Thanks given by:
#15
The only ones to keep should be gcc-debug-x86 and x64 I think. Each of those is about 15 megs zipped (so 30 megs in total).
Reply
Thanks given by:
#16
Do you want to be testing debug versions? Testing should be done in release then investigated in debug.
Reply
Thanks given by:
#17
It's easier just to test straight in debug - what's the real downside?
Reply
Thanks given by:
#18
Performance halving is not a real downside?
Reply
Thanks given by:
#19
No, you're only testing, not going to be running a production server on a pull request!
Reply
Thanks given by:
#20
No but we pride ourselves on performance, we need to know if the pull request feels slow.

And we need to know about release only issues since they tend to be nasty so we want to keep them off master.
Reply
Thanks given by:




Users browsing this thread: 1 Guest(s)