+- Cuberite Forum (https://forum.cuberite.org)
+-- Forum: Cuberite (https://forum.cuberite.org/forum-4.html)
+--- Forum: Development (https://forum.cuberite.org/forum-13.html)
+--- Thread: New Pull Request Builder (/thread-1458.html)
Pages:
1
2
RE: New Pull Request Builder - xoft - 04-23-2014
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.
RE: New Pull Request Builder - worktycho - 04-23-2014
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.
RE: New Pull Request Builder - worktycho - 04-23-2014
No, me being stupid and looking in the wrong place in the manual, its TRAVIS_PULL_REQUEST. derp.
RE: New Pull Request Builder - worktycho - 04-23-2014
So apart from ftp config I should be able to set up to store the artefacts and post the comment on build success.
RE: New Pull Request Builder - bearbin - 04-23-2014
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).
RE: New Pull Request Builder - worktycho - 04-23-2014
Do you want to be testing debug versions? Testing should be done in release then investigated in debug.
RE: New Pull Request Builder - bearbin - 04-24-2014
It's easier just to test straight in debug - what's the real downside?
RE: New Pull Request Builder - worktycho - 04-24-2014
Performance halving is not a real downside?
RE: New Pull Request Builder - bearbin - 04-24-2014
No, you're only testing, not going to be running a production server on a pull request!
RE: New Pull Request Builder - worktycho - 04-24-2014
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.