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 :|