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?
- Register a local shell runner
- Run a pipeline with some submodules and
GIT_STRATEGY: fetch
,GIT_SUBMODULE_STRATEGY: recursive
- Cancel or manually "corrupt" the runner build .git folder with
.git/modules/<submodule>/index.lock
- 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.
Edited by Nejc Habjan