Skip to content

Enable variable injection to Persistent Volume Claim name

What does this MR do?

Enables injecting variables to Kubernetes executor's setting.

Why was this MR needed?

This partially alleviates #27835. When the Persistent Volume Claim name is allowed to contain variable references, the user can manually create persistent build volumes up to their concurrency limit and inject $CI_CONCURRENT_ID in the PVC. This enables a reusable cached clone of the project, like with the docker executor. A full implementation of #27835 will of course be better, but this is a tolerable work around, and provides useful flexibility even after the full implementation exists. One could image, for example, project-specific volumes being useful in some cases.

What's the best way to test this MR?

  1. Get a Kubernetes cluster with a gitlab-runner configured to use it as a Kubernetes executor.
  2. Create PersistentVolumeClaims named buildvolume-0 and buildvolume-1
  3. Add this to the config.toml of a Kubernetes executor:
      name = "buildvolume-$CI_CONCURRENT_ID"
      mount_path = "/mnt/dynamic-pvc"
  1. Run two jobs on the runner in parallel. Write the job id to /mnt/dynamic-pvc/job.txt from the job.
  2. Later run two other jobs in parallel. Read job.txt from each. Observe that the file was persisted, and the copies are independent.

What are the relevant issue numbers?

  • Enables a manual work-around for #27835.
Edited by OK_MF

Merge request reports