[libvirt] [PATCH v4 7/7] tests: perform cross compiler builds on GitLab CI

[Daniel P. Berrangé]

On Wed, Apr 10, 2019 at 02:15:44PM +0200, Andrea Bolognani wrote:
> On Wed, 2019-04-03 at 11:41 +0100, Daniel P. Berrangé wrote:
> > GitLab CI provides some shared build runners that use Docker containers.
> > This resource can usefully run cross-compiled builds since all other CI
> > build testing is currently x86 only, and Travis CI is already very busy
> > testing native builds.
> 
> Fair warning: this is my first time looking at GitLab CI :)
> 
> [...]
> > +  script:
> > +    - mkdir vpath
> > +    - cd vpath
> > +    - ../autogen.sh $LIBVIRT_CONFIGURE_OPTS
> > +    - make -j $(getconf _NPROCESSORS_ONLN)
> 
> Using $LIBVIRT_CONFIGURE_OPTS will obviously not work, since the
> variable we bake in the containers is $CONFIGURE_OPTS. Though now
> that I think about it, I like the prefixed name better :)

Yes, of course it won't work and in fact I already had that fixed
but somehow I squashed it into a different patch I had locally which
wasn't posted in this series as posted.

> More generally, I dislike the fact that this is the same, but not
> quite the same, script as in Makefile.ci and .travis.yml... I assume
> we can't just use the ci-build targets here, the same way we do on
> Travis CI, because of how GitLab sets up their environment?

Our Makefile.ci runs docker itself so obviously needs to be invoked
from "host" context. We can do that in Travis since the build env
runs in a throwaway VM where docker is available as an opt-in.

With GitLab though, docker is a builtin feature of their CI so
you must tell them upfront what image to run in and your build
process will be always inside that.  There's no "host" context
in GitLab, you are always inside the container.

> > +deb9crossaarch64:
> > +  <<: *job_definition
> > +  image: quay.io/libvirt/buildenv-debian-9-cross-aarch64:master
> 
> You have 17 jobs defined here... Does GitLab not limit the number
> of concurrent jobs? And if not, why are we even using Travis CI for
> anything but macOS builds? O:-)

I'm unclear on what the actual limit is, but it looks much more
relaxed that under Travis. It looks to be determined largely by
how many projects are currently competing for resources. IOW
sometimes you might end up with 1 or 2 jobs running in parlallel.
Other times you might get 10 or 15 jobs in parallel. Depends what
is available.

We should monitor how well GitLab works over a few months, and
if it works better we can certainly move the non-macOS jobs
off Travis.

> About the jobs themselves: the names should match the name of the
> image, eg. debian-9-cross-armv6l; and I assume there is no way to
> avoid having to repeat "quay.io/libvirt/buildenv-" and ":master"
> over and over again, is there?

Not that I've seen so far.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|