mingw-cross-env-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Mingw-cross-env-list] Build automation and binary distribution (was Qt5


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:

[…]
(like pulling a known previously built binary or source package right from an MXE github repo similar to what I mentioned above concerning the Travis-CI issue Tim explained above).

I noticed Tim's pull request was closed, but I hope that MXE does incorporate Travis-CI into the workflow and that it is a high priority. Not only does that immediately notify the commiter that they have broken the build, it notifies anyone making a pull request that they will break the build, and others such as myself can actually look at the build history and immediately know that the build is failing before even cloning it just to find out it doesn't build.

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]
https://github.com/mxe/mxe/issues/140
https://github.com/mxe/mxe/issues/129
https://github.com/mxe/mxe/issues/145


reply via email to

[Prev in Thread] Current Thread [Next in Thread]