'gitlab-runner exec' doesn't work with submodules with relative paths
Status update (2023-02-04)
- As indicated here, we do not plan to add new features or work on known bugs for
gitlab-runner exec
.
Scenario
- Consider a project
top
hosted atgitlab.example.com/foo/top.git
. -
top
has a single submodulesub
, hosted atgitlab.example.com/foo/sub.git
.- In its
.gitmodules
file,top
specifies a relative path tosub
:url = ../sub.git
.
- In its
- You have a local repostory of
top
, acquired viagit clone git@gitlab.example.com:foo/top.git
- This local repo thus has a remote
origin
referring togit@gitlab.example.com:foo/top.git
- This local repo thus has a remote
Problem
If you cd
into this local repo top
and run gitlab-ci-multi-runner exec docker somejob
, the runner will clone the repository via a bind-mounted volume into the container.
The problem is this: When the submodules are updated (manually, or via GIT_SUBMODULE_STRATEGY
), git will try to access them via filesystem-local relative paths. This happens because the origin
is a local path.
Solution
I'm not sure what the best solution to this problem is. One thought that occurs to me though, is that the submodules are probably already cloned and available the .git/modules
of the parent repository. gitlab-ci-multi-runner
already has to access the bind mount to clone the parent, perhaps it could do the same for the submodules? The question would be when and how.
- It could mangle the
.gitmodules
file and change theurl
s to refer to the bind mount.- This should work whether the user uses
GIT_SUBMODULE_STRATEGY
orgit submodule update --init
directly.
- This should work whether the user uses
Edited by Darren Eastman