My understanding is that the relative module address should make the recursive clone just work. However, I get this:
Submodule ‘lib/b’ (https://gitlab-ci-token:[MASKED]@gitlab.com/signal-essence/delete/b.git) registered for path ‘lib/b’
Synchronizing submodule url for ‘lib/b’
Cloning into ‘/builds/signal-essence/delete/a/lib/b’…
remote: The project you were looking for could not be found or you don’t have permission to view it.
fatal: repository ‘https://gitlab.com/signal-essence/delete/b.git/’ not found
Duplicating my own respond from another post: here was my solution:
Sorry if this has already been answered. I found my solution: say you’ve got a private group G with projects P1 and P2. P1 includes submodule …/P2.
Toy need to go into the P2 projects settings, under CI/CD settings (NOT PERMISSIONS ! Which is what threw me). Under the CICD settings, you go to something like “pipeline tokens” or something. I have no power now and 0.2 mbits/sec on my phone, so can’t easily check exactly.
But under P2->settings->CI/CD->pipeline token, add the group GitLab.COM/myname/G/P1. This gives the P1 pipeline access to clone the P2 project.
I got the same issues and tried to add the access in the P2 project parameter, in Settings → CI/CD → Token Access → Allow access to this project with a CI_JOB_TOKEN
However , I always got this error when I try to add a project :
The target_project that you are attempting to access does not exist or you don’t have permission to perform this action
I tried with absolute and relative paths, and different accounts (owner or maintainer). In the end, my only possibility was to disable the Allow access to this project with a CI_JOB_TOKEN parameter.