Support Git strategy with the GitLab Runner Kubernetes executor
Release notes
In GitLab CI, the Git strategy feature enables users to choose either git clone
or git fetch
when executing a CI job. With this new feature, users can now configure and use Git strategy when using the GitLab Runner Kubernetes executor.
Status update 2021-05-10
- Feature complete and will ship in 13.12
Description
The git_strategy
CI/CD setting currently doesn't work with the Kubernetes executor. This was discussed internally(internal-only link) and we determined that it's probably possible with a shared volume.
Additional Notes:
- The Kubernetes executor does not store the old builds/repo for reuse with the next build in the
builds/
folder - This leads into having to do a
git clone
for every job instead of doing agit fetch
after the first build, which can create unnecessary load when you have large repositories. - Non root images, we need to have the build directory writeable for non root images, but not 777 permissions, something like #1736 (comment 376415811)
I'm proposing that we should support git_strategy
with the Kubernetes executor.
Proposal
Allow the user to configure the volume type for the builds_dir
so what they desire, for example:
PVC:
[[runners]]
[runners.kubernetes]
[runners.kubernetes.builds_dir.pvc]
name = "pvc-1"
mount_path = "/path/to/mount/point1"
# OR have runner check if the builds dir is defined by the user, if it is used that if not default of emptyDir
[[runners]]
[runners.kubernetes]
[runners.kubernetes.pvc]
name = "pvc-1"
mount_path = "/builds"
EmptyDir:
[[runners]]
[runners.kubernetes]
[runners.kubernetes.builds_dir.empty_dir]
name = "empty-dir"
mount_path = "/path/to/empty_dir"
medium = "Memory"
# OR have runner check if the builds dir is defined by the user, if it is used that if not default of emptyDir
[[runners]]
[runners.kubernetes]
[runners.kubernetes.builds_dir.empty_dir]
name = "empty-dir"
mount_path = "/builds"
medium = "Memory"
If none is set, we default of the basic EmptyDir
that we are defaulting too right now. We also need to try and be consistent with how the docker executor works.
For the volume types, we should use the same structure as we have for KubernetesVolumes