qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 0/0] .travis and minor compile fixes


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH v2 0/0] .travis and minor compile fixes
Date: Wed, 25 Sep 2013 10:33:12 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Tue, Sep 24, 2013 at 03:19:29PM +0100, Alex Bennée wrote:
> 
> address@hidden writes:
> 
> > On Mon, Sep 23, 2013 at 05:07:27PM +0100, address@hidden 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



reply via email to

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