Runner setup

First, the runner has to be set up as a custom runner and registered (using gitlab-runner register) with the corresponding GitLab instance following the standard procedure. When prompted for "Enter an executor:", type "custom".

The config (example in runner_config) needs to be adjusted to point with their config_exec and run_exec entries to the respective scripts in the runner_scripts folder. For a runner registered as root, the config.toml file is located in /etc/gitlab-runner; for non-root it is in ~/.gitlab-runner (Ref).

Scripts need to be selected depending on runner privileges: root (allows change of users) or user (can only execute jobs as this user). Note, that paths in those scripts might need to be adjusted.

Authentification takes place by private-public key pairs. In case of root runners, the corresponding authorized_keys file with the public keys needs to be in /etc/gitlab-runner; for non-root ones in ~/gitlab-runner/.

Cx with .gitlab-ci.yml

First, the username to authenticate with has to be set using the AUTH_USER variable. Second, a key pair has to be generated, of which the private key is added as a CI variable AUTH_KEY in reposity settings > CI/CD. The public one has to be added to ~/gitlab-runner/authorized_keys, where ~ signifies the AUTH_USER's home.

Jobs, which have the variable SUBMIT_TO_SLURM set, will have their script submitted to SLURM. Options for SLURM's salloc are configurable by setting the respective environment variables preceded by SLURM_ in the variables section of the job definition.

Jobs without SUBMIT_TO_SLURM will have their script executed on the frontend of the cluster.

An example .gitlab-ci.yml file can be found in the root of this repository.