Openshift runner is re-registered when gitlab-runner-runner pod restarts
Summary
When a gitlab-runner-runner-xxxx-xxxx pod in Openshift restarts for any reason, this is treated as a re-registration of the runner. When using project specific runners in several projects, the newly registered runner is only enabled by default for the project which initiated the original registration with its registration-token. This leads to pipelines being stuck in other projects which had the runner enabled until we manually visit every project and enable that runner. If the runner has been locked to current projects through the GitLab UI this is not preserved either so after a restart it is available for everyone again. The "old" registrations are not cleaned up either as mentioned in another issues.
Steps to reproduce
- Register a project specific runner in Openshift
- Enable it for atleast an additional project
- Restart the gitlab-runner-runner-xxxx-xxxx pod in your Openshift project
- Visit the Settings > CI/CD > Runners page of the projects and observe a new registration present.
- Notice that the new registration is not enabled for the additional project(s) mentioned in step 2. .gitlab-ci.yml
Actual behavior
Openshift gitlab-runner-runner-xxxx-xxxx pod restart triggers a runner re-registration. Project lock is not preserved and the runner needs to be re-enabled for additional projects and re-locked.
Expected behavior
Openshift gitlab-runner-runner-xxxx-xxxx pod uses the already established registration after a restart. Project lock is to be preserved and the runner should stay enabled for projects where it was previously enabled.
Relevant logs and/or screenshots
Environment description
GitLab Enterprise Edition 14.3.3-ee
Openshift 4.6
GitLab Operator 1.1.0
Executor kubernetes
config.toml contents
concurrent = 10
check_interval = 30
log_level = "info"
listen_address = '[::]:9252'
Used GitLab Runner version
gitlab-runner 14.2.0
Possible fixes
N/A