Dedicated Gitlab Runner/Executor¶

Starting Position¶

To publish new content on the ALPS repositiory, one has to log in to the ALPS CVMFS server as the release user, start a CVMFS transaction, copy/modify the relevant files in(to) the CVMFS repo, and publish the changes

In a pipeline using vanilla shared Gitlab runners on Kubernetes, one can build containers etc., but for copying or polling the results to the CVMFS release server, such a runner would need credentials to copy the results/artifacts from the shared runner context to cvmfs-alps. This would need to be handled securely and also be compatible with the general 2FA roll out.

Instead, we are going for plain shell runner on the CVMFS release server, running in context of the alpscv. The runner starts an executor all in the alpscv user context, registering with a predefioned token at the Gitlab instance, so that necessary release steps could be put in a deploy stage or so.

Setting up a Runner in Gitlab¶

To prepare a runner in Gitlab, go in the project, were the runner should live, to Settings --> CI/CD and expand the Runner section.

Adding a new runner via new project runenr will open a menu. If the run untagged jobs option is not checked, the runner will only run jobs that have the right tags set in their configs corresponding to the allowed tags (which could be handy to control, that CVMFS release jobs run only in a runner with all the requirements).

We lock the runner also to this project as to avoid problems with jobs, that do not belong onto the CVMFS release server.

Followingly, one should be presented with the endpoint information as well as a token, so that the runner can be executed and can contact its Gitlab instance. For the moment, we have disabled here shared runners as to avoid jobs accientially going to the wrong runners - which should better be handled by proper tagging.

The final runner config could look like

Registering the Runner on the CVMFS Release Server¶

The release node needs the Gitlab runner installed - if not already present, please follow https://docs.gitlab.com/runner/install/linux-repository.html

Logged in as the release user, we have to register the gitlab runner first. We will prepare a simple shell runner/executor, that connects to the DESY Gitlab instance with the token, that we got in the previous step

[alpscv@alps-cvmfs]~% gitlab-runner register -u https://gitlab.desy.de --token secret-token-from-registration --executor shell --name hartmath-test-runner-thingy

The resulting config should by default then get written under ~HOME/.gitlab-runner/config.toml

Executing the Runner on the CVMFS Release Server¶

With the runner registered (i.e., a config prepared), we can start the shell runner then with

[alpscv@alps-cvmfs]~% gitlab-runner run --working-directory /home/alpscv/GitlabRunnerWorkdir  --config  $HOME/.gitlab-runner/config.toml

(where we have prepared a work dir in advance /home/alpscv/GitlabRunnerWorkdir as not to clutter the user home dir)

The shell runner/executor should now appear in the projects CI/CD runner section as alive and well.

Pipeline jobs should then be directed to this runner, depending on their tags and if the runner accepts only correctly tagged jobs or all.

If everything works, detach the runner into the background `nohup gitlab-runner ... & ` ) (until we have a systemd unit). If the runner does not appear in the runner section, check if it is alive and start it anew if necessary

Next Steps¶

Prepare a systemd unit to automatically start the runner during start ups.