|
From: | Tony Theodore |
Subject: | [Mingw-cross-env-list] Build automation and binary distribution (was Qt5 Shared / Travis-CI) |
Date: | Sat, 8 Mar 2014 03:37:55 +1100 |
On 7 Mar 2014, at 20:51, Jonathan Greig <address@hidden> wrote:
Travis-CI would be a very welcome addition to MXE, the benefits are very clear and it’s the “nicest” CI system I’ve seen. However, using github as a binary cache to workaround the time limits doesn’t seem like a reasonable use of either service to me. I’ve seen some blog posts about using S3 as a cache, but those are aimed at reducing build times, not breaking a build into restartable stages. I’d rather use some distributed buildbot system that can take up idle time on various user-contributed hardware, possibly using our S3 bucket as cache. That can’t work as no normal user could possibly upload a full build anywhere. Maybe some hybrid of testing and collecting results from distributed machines and then building known working versions on something with a backbone connection to upload the build artefacts?. I know that is sub-optimal, but a full build of MXE is many hours and many gigabytes - not really suited to services designed to encourage unit testing and code sharing (in my mind). A clean solution to this would be great, there are related issues[1] and recurring themes. An apt repository would probably work and remove the need for caching, but how would we test and populate that in the first place? Suggestions welcome, it could be that I’m too conservative in my estimation of how Travis-CI and GitHub should be used. Cheers, Tony [1] |
[Prev in Thread] | Current Thread | [Next in Thread] |