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.
First, the runner has to be set up as a custom runner and registered 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.
