[lxc-devel] [PATCH] add travis-ci support to LXC github repo

Mon Dec 23 19:31:27 UTC 2013

On Mon, Dec 23, 2013 at 02:14:37PM -0500, Ranjib Dey wrote:
> we'll have several other advantages with travis. the build status can be
> reflected on the project page easily, downstream clients (language specific
> bindings or other lxc dependent libraries) can reuse the build status to
> trigger their own builds , which we'll allow then to catch any breakage
> early on.
> 
> but the whole model is very tied to github and pull request based
> development, so unless lxc is aopting that, travis usage might not yield a
> lot of value,

Yeah, I don't think we'll be moving to a github-only model anytime soon
which is why I've never bothered spending more time into Travis-CI and
instead have a very extensive automated build testing and testsuite runs
done externally.

As good as github can be, I don't want us to be locked in it so I'd be
concerned if our development workflow required everyone to have a github
account and use github pull requests.

Also, we will never let github auto-merge (using the merge button on
pull requests) as we have a policy of editing every single commit to add
our Acked-by tag, so in practice the only thing Serge and I do with
github pull requests is download the <url>.patch file and run git am on
them, then manually closing the pull request.

FWIW, the tests I'm currently running on all of my branches and on most
major changes I'm reviewing is:
 - Build on Ubuntu amd64, i386 and armhf (hardware builders)
 - Build on Ubuntu powerpc and arm64 (manual, cross-compile)
 - Build on Debian amd64, i386 and armhf (hardware builders)
 - Build on Debian powerpc and arm64 (manual, corss-compile)
 - Build with the current Android NDK (cross-compile)
 - Build with the clang compiler on Ubuntu amd64
 - Build and generate html for all documentation
 - Build using the coverity tools and upload the result to Coverity SCAN
 - Run upstream tests on amd64, i386 and armhf
 - Run minimal tests on Android (manual)

All of the above takes around 15min to run, with all the non-arm tests
finishing within 2-3 minutes. I need to get a better kernel on my ARM
hardware as it's ridiculously slow for what it's (quadcore, 2GB of RAM
with a SATA3 SSD...).

> 
> 
> 
> 
> On Mon, Dec 23, 2013 at 2:03 PM, S.Çağlar Onur <caglar at 10ur.org> wrote:
> 
> > Hi Serge,
> >
> > On Mon, Dec 23, 2013 at 10:42 AM, Serge Hallyn <serge.hallyn at ubuntu.com>
> > wrote:
> > > Is this something you've discussed with Stéphane?  A set of tests is
> > > already being run on his own server, so I'm not sure this is needed.
> > > There is the "the more testing the better" point of view, but I've seen
> > > more time wasted trying to debug test "breakages" that were actually
> > > host system errors (at least on one of the test harnasses we were using
> > > for lxc) than real errors found, so I'm a bit hesitant.
> >
> > No, I haven't discussed this with Stéphane. IMHO this only ensures
> > that master builds fine after a commit. We don't run test cases as
> > travis-ci vms not capable of creating LXC containers for now. One
> > advantage of travis over others is its integration with github. When
> > someone sends a pull request, travis builds that changeset on top of
> > master so that one can see whether merging the pull request is OK or
> > not.
> >
> > But if you think that's unnecessary, or think that this duplicates
> > what qa.linuxcontainers.org does then please feel free to drop this :)
> >
> > > I'd be more interested in new tests for specific use cases - like a
> > > unprivileged container create/start - which aren't currently being
> > > tested, or cleanups to the existing tests cases to make them more
> > > robust and useful.
> > >
> > > thanks,
> > > -serge
> > >
> > > Quoting Ranjib Dey (dey.ranjib at gmail.com):
> > >> +1 . too bad travis run on openvz :-( . else we could have run the
> > tests .
> > >>
> > >>
> > >> On Sun, Dec 22, 2013 at 11:58 PM, S.Çağlar Onur <caglar at 10ur.org>
> > wrote:
> > >>
> > >> > Travis is a free hosted CI platform for the open source community. It
> > >> > integrates
> > >> > well with github and enables continous builds/tests for both
> > repository
> > >> > itself
> > >> > and all the pull requests so that one can quickly see the result of
> > the
> > >> > possible
> > >> > merge.
> > >> >
> > >> > This yml file is one of the few required steps to enable travis-ci
> > support
> > >> > for
> > >> > LXC github repo. One of you guys still need to sign in travis-ci
> > through
> > >> > GitHub OAuth
> > >> > and enable travis support from its profile page
> > >> > https://travis-ci.org/profile
> > >> >
> > >> > As an example
> > >> > https://travis-ci.org/caglar10ur/lxc-upstream/builds/15872074 can be
> > seen
> > >> >
> > >> > Signed-off-by: S.Çağlar Onur <caglar at 10ur.org>
> > >> > ---
> > >> >  .travis.yml | 9 +++++++++
> > >> >  1 file changed, 9 insertions(+)
> > >> >  create mode 100644 .travis.yml
> > >> >
> > >> > diff --git a/.travis.yml b/.travis.yml
> > >> > new file mode 100644
> > >> > index 0000000..e7e3776
> > >> > --- /dev/null
> > >> > +++ b/.travis.yml
> > >> > @@ -0,0 +1,9 @@
> > >> > +language: c
> > >> > +compiler:
> > >> > +  - gcc
> > >> > +# failing with python
> > >> > +#  - clang
> > >> > +before_install:
> > >> > + - sudo apt-get update -qq
> > >> > + - sudo apt-get install -qq libapparmor-dev libcap-dev libseccomp-dev
> > >> > python3-dev
> > >> > +script: ./autogen.sh && CFLAGS="-g -O2 -fstack-protector
> > >> > --param=ssp-buffer-size=4 -Wformat -Werror=format-security"
> > >> > CPPFLAGS="-D_FORTIFY_SOURCE=2" CXXFLAGS="-g -O2 -fstack-protector
> > >> > --param=ssp-buffer-size=4 -Wformat -Werror=format-security"
> > FFLAGS="-g -O2"
> > >> > LDFLAGS="-Wl,-Bsymbolic-functions -Wl,-z,relro" ./configure
> > --prefix=/usr
> > >> > --sysconfdir=/etc --bindir=/usr/bin
> > --libdir=/usr/lib/x86_64-linux-gnu/
> > >> > --localstatedir=/var --includedir=/usr/include --disable-rpath
> > >> > --enable-python --enable-tests --enable-apparmor --with-distro=ubuntu
> > &&
> > >> > make -j4
> > >> > --
> > >> > 1.8.3.2
> > >> >
> > >> > _______________________________________________
> > >> > lxc-devel mailing list
> > >> > lxc-devel at lists.linuxcontainers.org
> > >> > http://lists.linuxcontainers.org/listinfo/lxc-devel
> > >> >
> > >
> > >> _______________________________________________
> > >> lxc-devel mailing list
> > >> lxc-devel at lists.linuxcontainers.org
> > >> http://lists.linuxcontainers.org/listinfo/lxc-devel
> > >
> > > _______________________________________________
> > > lxc-devel mailing list
> > > lxc-devel at lists.linuxcontainers.org
> > > http://lists.linuxcontainers.org/listinfo/lxc-devel
> >
> >
> >
> > --
> > S.Çağlar Onur <caglar at 10ur.org>
> > _______________________________________________
> > lxc-devel mailing list
> > lxc-devel at lists.linuxcontainers.org
> > http://lists.linuxcontainers.org/listinfo/lxc-devel
> >

> _______________________________________________
> lxc-devel mailing list
> lxc-devel at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-devel

-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20131223/9fd35e52/attachment.pgp>