I prefer avoiding relative paths for submodules even when on the same instance since these are prone to errors, sometimes finding out the relative path is time consume and there may be issues with forking.
My main repo is using another one as a submodule and both are in the same group on the same instance but with slightly different paths. Both repos are PRIVATE. The runner has been registered as group runner for that instance and group and is able to build all projects. That is, before I added the submodule.
I tried both SSH and HTTPS with the following errors as a result:
SSH
Host key verification failed.fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.HTTPS
remote: The project you were looking for could not be found or you don't have permission to view it.fatal: repository 'https://gitlab.example.de/user/example/example-group/project-development-setup.git/' not found
Obviously when submodule initing locally I need SSH key in place, which I have also added. However, I wasn't expecting for that to be the case with CI jobs that clone a submodule in the same group (but not subgroup I guess).
If I don't want to use relative URI for the submodule, how else would I add authentication to for the git submodule commands applied through the GIT_SUBMODULE_STRATEGY, GIT_SUBMODULE_PATHS and other GitLab CI variables?