Inspired by the talk at FOSDEM, I’ve just enabled GitLab’s continuous integration (CI) for building make distcheck
for Walbottle, and it was delightfully easy. The results are on Walbottle’s GitLab page.
Steps
- Create a
ci
branch to contain the mess you’ll make while iterating over the correct compile steps. - Create and push a
.gitlab-ci.yml
file containing build rules similar to the following:image: debian:unstable before_script: - apt update -qq - apt install -y -qq build-essential autoconf automake pkg-config libtool m4 autoconf-archive gtk-doc-tools libxml2-utils gobject-introspection libgirepository1.0-dev libglib2.0-dev libjson-glib-dev stages: - build # FIXME: Re-enable valgrind once running the tests under it doesn’t take forever (it causes timeouts). # Re-add valgrind to apt-install line above build-distcheck: stage: build script: - mkdir build - cd build - ../autogen.sh --disable-valgrind - make V=1 VERBOSE=1 - DISTCHECK_CONFIGURE_FLAGS=--disable-valgrind make distcheck V=1 VERBOSE=1 # The files which are to be made available in GitLab artifacts: paths: - build/*
- Iterate a few times until you get all the dependencies right.
- Fix any problems you find (because this might well find problems with your dependency declaration in
configure.ac
, or otherdistcheck
problems in your project). - Merge
ci
tomaster
and profit from CI results on every branch and master commit.
Looking at the .gitlab-ci.yml
file
For information on the overall layout of the YAML file, and the phases available, you’re best off looking at the comprehensive GitLab documentation. Here are some notes about the autotools-and-C–specific bits of it:
- The
image
is a Docker image; I picked a Debian one from the Docker hub. - Package installation seems to need to be done in the
before_script
phase, or the packages can’t be found (which is presumably a protection against rogue build systems). - I chose to build
distcheck
in my build rule because that runs the build, runs the tests, and tries varioussrcdir
?builddir
configurations. You can add other build targets (likebuild-distcheck
to try other build setups). - Pass
V=1 VERBOSE=1
to get verbose build and test log output in your CI build logs, otherwise you will struggle to work out what is causing any failures. - Note that
configure
flags passed to./configure
are not automatically passed in again when./configure
is run as part ofdistcheck
— so useDISTCHECK_CONFIGURE_FLAGS
for that. Ideally, your project will be less fragile than mine, and hence not need any of this. - Export the whole
build
directory as an artifact on success, so you can look at any of the build objects, or the generated tarball, or documentation. You could limit this (for example, to just the tarball) if you’re sure you’ll never need the rest of it.