New Pull Request Builder

[xoft]

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.

[worktycho]

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.

[worktycho]

No, me being stupid and looking in the wrong place in the manual, its TRAVIS_PULL_REQUEST. derp.

[worktycho]

So apart from ftp config I should be able to set up to store the artefacts and post the comment on build success.

[bearbin]

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).

[worktycho]

Do you want to be testing debug versions? Testing should be done in release then investigated in debug.

[bearbin]

It's easier just to test straight in debug - what's the real downside?

[worktycho]

Performance halving is not a real downside?

[bearbin]

No, you're only testing, not going to be running a production server on a pull request!

[worktycho]

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.