'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 at gitlab.example.com/foo/top.git.
• top has a single submodule sub, hosted at gitlab.example.com/foo/sub.git.
  • In its .gitmodules file, top specifies a relative path to sub: url = ../sub.git.
• You have a local repostory of top, acquired via git clone git@gitlab.example.com:foo/top.git
  • This local repo thus has a remote origin referring to git@gitlab.example.com:foo/top.git

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 the urls to refer to the bind mount.
  • This should work whether the user uses GIT_SUBMODULE_STRATEGY or git submodule update --init directly.