Gitlab runners with nspawn

pdo debian eng sw systemd

This is a first post in a series about trying to setup a gitlab runner based on systemd-nspawn. I published the polished result as nspawn-runner on GitHub.

The goal

I need to setup gitlab runners, and I try to not involve docker in my professional infrastructure if I can avoid it.

Let's try systemd-nspawn. It's widely available and reasonably reliable.

I'm not the first to have this idea: Federico Ceratto made a setup based on custom runners and Josef Kufner one based on ssh runners.

I'd like to skip the complication of ssh, and to expand Federico's version to persist not just filesystem changes but also any other side effect of CI commands. For example, one CI command may bring up a server and the next CI command may want to test interfacing with it.

Understanding gitlab-runner

First step: figuring out gitlab-runner.

Test runs of gitlab-runner

I found that I can run gitlab-runner manually without needing to go through a push to Gitlab. It needs a local git repository with a .gitlab-ci.yml file:

mkdir test
cd test
git init
cat > .gitlab-ci.yml << EOF
tests:
 script:
  - env | sort
  - pwd
  - ls -la
EOF
git add .gitlab-ci.yml
git commit -am "Created a test repo for gitlab-runner"

Then I can go in the repo and test gitlab-runner:

gitlab-runner exec shell tests

It doesn't seem to use /etc/gitlab-runner/config.toml and it needs all the arguments passed to its command line: I used the shell runner for a simple initial test.

Later I'll try to brew a gitlab-runner exec custom invocation that uses nspawn.

Basics of custom runners

A custom runner runs a few scripts to manage the run:

config, to allow to override the run configuration outputting JSON data
prepare, to prepare the environment
run, to run scripts in the environment (might be ran multiple times)
cleanup to clean up the environment

run gets at least one argument which is a path to the script to run. The other scripts get no arguments by default.

The runner configuration controls the paths of the scripts to run, and optionally extra arguments to pass to them

Next steps

My next step will be to figure out possible ways of invoking nspawn for the prepare, run, and cleanup scripts.