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