On Tue, Sep 24, 2013 at 03:19:29PM +0100, Alex Bennée wrote: > > stefa...@redhat.com writes: > > > On Mon, Sep 23, 2013 at 05:07:27PM +0100, alex.ben...@linaro.org wrote: > >> Given I found a couple of issues while doing this I think this is > >> useful alongside the existing buildbot efforts. It allows developers > >> to run simple smoke-tests without access to the buildbot > >> infrastructure (but of course needing github/travis access, free for > >> FLOSS projects). > <snip> > > Travis CI allows individual developers to modify the build > > configuration. This is much more friendly. > > > > Can you explain the limitations of Travis CI? For example, does it > > start costing money at some point? > > It is free to all public repositories. There is a "Pro" service which > allows you to set-up testing on private repos (much like GitHubs model). > The actual code for Travis is open source > (https://github.com/travis-ci/travis-ci) although I'm not aware of > anyone setting up another instance of it. I'm not aware of any plans to > charge open source projects for it's use. > > The main limitation is the host build VM is Ubuntu 12.04 LTS. I'm not > sure how much of a limitation this is for the general developer - > Debian/RPM differences aside I would expect most compile failures to be > caught regardless of the host.
Hmm...that misses extra bases we cover: * Solaris, FreeBSD, Mac OS, etc hosts * Stable distros with older library versions (e.g. Red Hat Enterprise Linux 5.x) * Different gcc versions report different warnings > I don't think this should attempt to replace other CI efforts. I know > that Linaro runs some tests through it's LAVA infrastructure and that's > an area I'm likely to look at expanding. The LAVA infrastructure is more > suited to testing on non-x86 hardware and running system image/kvm > integration tests. Having said that I think it can certainly act as a > good gatekeeper into "master" - if your not passing the Travis tests > then the branch should probably not be merged. I would like to replace buildbot because the utility vs maintenance ratio is too low (but still better than no continuous integration at all). The ideal system allows untrusted users to build their own source trees and make modifications to their build configuration. That way everyone is able to take advantage of continuous integration/build farm. Stefan
