GitLab now enforces expiry dates on tokens that originally had no set expiration date. Those tokens were given an expiration date of one year later. Please review your personal access tokens, project access tokens, and group access tokens to ensure you are aware of upcoming expirations. Administrators of GitLab can find more information on how to identify and mitigate interruption in our documentation.
First, the runner has to be set up as a custom runner and registered with the corresponding GitLab instance following the standard procedure.
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.
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.
# 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.
An example `.gitlab-ci.yml` file can be found in the root of this repository.
