Enable variable injection to Persistent Volume Claim name
What does this MR do?
Enables injecting variables to Kubernetes executor's volumes.pvc.name
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?
- Get a Kubernetes cluster with a gitlab-runner configured to use it as a Kubernetes executor.
- Create
PersistentVolumeClaim
s namedbuildvolume-0
andbuildvolume-1
- Add this to the config.toml of a Kubernetes executor:
[[runners.kubernetes.volumes.pvc]]
name = "buildvolume-$CI_CONCURRENT_ID"
mount_path = "/mnt/dynamic-pvc"
- Run two jobs on the runner in parallel. Write the job id to
/mnt/dynamic-pvc/job.txt
from the job. - 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