Skip to content

Fix lockfile cleanup for submodules

What does this MR do?

In addition to the git/{index,shallow,HEAD,config}.lock files currently being cleaned from corrupted previous runs, this matches additional lockfiles inside .git/modules if a GIT_SUBMODULE_STRATEGY is defined. It matches files recursively only if the submodules are updated recursively (I expected there might be a performance impact otherwise).

Why was this MR needed?

Currently, the runner cleans up corrupted .git lockfiles before attempting an update, but not for submodules. This makes using submodules with GIT_STRATEGY: fetch unreliable and people have to resort to clone which is a lot slower, especially with many nested submodules.

What's the best way to test this MR?

  1. Register a local shell runner
  2. Run a pipeline with some submodules and GIT_STRATEGY: fetch, GIT_SUBMODULE_STRATEGY: recursive
  3. Cancel or manually "corrupt" the runner build .git folder with .git/modules/<submodule>/index.lock
  4. Re-run a job: there should be no fatal: Unable to create '/builds/.../<project>/.git/modules/<submodule>/index.lock': File exists. output

What are the relevant issue numbers?

Closes #27204 (closed).

Slightly related but more expensive approach: #4600.

🛠 with at Siemens

Edited by Nejc Habjan

Merge request reports