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 :) 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? > +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:-) 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? -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
