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.
- Create a
cibranch to contain the mess you’ll make while iterating over the correct compile steps.
- Create and push a
.gitlab-ci.ymlfile 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 other
distcheckproblems in your project).
masterand profit from CI results on every branch and master commit.
Looking at the
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:
imageis a Docker image; I picked a Debian one from the Docker hub.
- Package installation seems to need to be done in the
before_scriptphase, or the packages can’t be found (which is presumably a protection against rogue build systems).
- I chose to build
distcheckin my build rule because that runs the build, runs the tests, and tries various
builddirconfigurations. You can add other build targets (like
build-distcheckto try other build setups).
V=1 VERBOSE=1to 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
configureflags passed to
./configureare not automatically passed in again when
./configureis run as part of
distcheck— so use
DISTCHECK_CONFIGURE_FLAGSfor that. Ideally, your project will be less fragile than mine, and hence not need any of this.
- Export the whole
builddirectory 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.