Skip to content

Allow disabling recursion when setting permissions on windows volume

What does this MR do?

Allow disabling recursion when setting permissions on a windows volume in the Kubernetes executor.

Why was this MR needed?

Setting permissions can take hours if there are many folders. Software projects tend to have a plethora of folders.

This MR solves the problem by allowing skipping the recursion when setting permissions. The permissions are set to be inherited from the root folder, so all files added later will default to being accessible. So as long as there are no relevant existing files with stricter permissions, this will work fine. A user using this setting can ensure the volume has the correct permissions ahead of time; skipping the hour of processing at the beginning of every build job.

New setting name: runners.kubernetes.init_permissions_recursion_disabled.

What's the best way to test this MR?

  1. Configure a gitlab-runner using Windows Kubernetes nodes to use a persistent volume for the build area.
  2. Run any job from a large project. The project will be cloned to the volume.
  3. Run another job for the same project later, such that the same volume is used.
  • Before this MR, the init-permissions container takes a long time. Even times out with default settings.
  • After this MR, the init-permissions container runs quickly also when the volume has data.

What are the relevant issue numbers?

This is one of two alternative solutions to #36829. The other one is !4324 (merged), which unconditionally removes the recursion. It's more reckless, but does not require a new option.

Edited by OK_MF

Merge request reports