Skip to content

feat: add optional persistent volume to save runner token after registration

Christian Patry requested to merge chpat/gitlab-runner:cpa/add-token-persistence into main

What does this MR do?

This MR add an optional attribute to make the volume /home/gitlab-runner/.gitlab-runner persistent.

This change allow a runner to keep it's runnerToken across reboot and deletion, ensuring Gitlab can keep track of it.

Why was this MR needed?

/!\ I acknowledge this MR is a naive approach to solve our issue.
I saw several Gitlab issues that we are not the only ones with these problems.
I am humbly sharing this first draft solution to start discussions.

We encounter several issue with the current behaviour:

  • Pods are short-life entity. Each restart/deletion create a new runner in our Gitlab.
  • Often, the old runner is not correctly unregistered from Gitlab, so we have a lot of offline runners to clean every month
  • (Maybe it's a separate issue) When a new runner is registered to a project, it's not always enable and ready to use. So the job are stuck when a runner is restart, and someone with maintainer access need to enable the runner manually.
  • In our use case, runner are a stable entity, no need to link the life cycle of the pod with the life cycle of the runner inside gitlab.

What's the best way to test this MR?

  1. This MR has been tested on our EKS cluster.

  2. Add the following values to your deployment:

persistence:
  enabled: true
unregisterRunners: false
  1. Deploy a runner
  2. Check in Gitlab that the runner is available
  3. Delete the pod
  4. After the restart, the runner is still available in gitlab, with the same number, because the runnerToken has been reused.

What are the relevant issue numbers?

You can find several existing issues more or less linked to the issue I am trying to fix.

For example:

Known issues

  • The runnerToken is now in a persistent pv. I don't see a lot of issue with that because if you have access to the pvc, you may already have access to the secret runnerRegistrationToken, which is a lot more interesting.
  • The persistence do not work with unregisterRunners: true, because the runner is unregistered when stopped, and not registered back during the restart.
  • You need to destroy the helm install or remove the file inside the pvc to register a new runner. Which is kind of the point of this.

Best regards,

Edited by Christian Patry

Merge request reports