GitLab Next

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 a git 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