# 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](https://docs.gitlab.com/runner/configuration/advanced-configuration.html)).

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.