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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
