Submodules in CI/CD not accessible

Gilab CI/CD is not checking out my submodules, even though I’m using relative paths

I have 2 projects in a group named ‘delete’.
The group/project hierarchy is:

--- delete/a
--- delete/b
` ``

I do

git clone git@gitlab.com/ccrome/delete/a
cd a
mkdir lib
git submodule add …/b lib/b
git commit & push.

my .gitmodules looks like:

[submodule “lib/b”]
path = lib/b
url = …/b.git

and my .gitlab-ci.yml is

stages:

• build

build:
image: alpine:3.17.2
stage: build
variables:
GIT_SUBMODULE_STRATEGY: recursive
script:
- ls -l

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.

This must be a new feature

Hi,

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.

Did someone face the same issue ?

I had the same problem and got it solved by adding P1 as described by @ccrome under “Allow CI job tokens from the following projects to access this project”.

Thanks mate!

I have the same problem with @micazeve .
I have a main repo called main_repo this repo includes a submodule called sub_repo inside the main directory. I go to the sub_repo>settings>CICD>token access
Then I enter the link ip_address/project/main_repo/git_cicd_example and see the same error:

The target_project that you are attempting to access does not exist or you don’t have permission to perform this action

I also tried adding https:// part to the link but none of them is successful.
Could anyone help us how to solve the problem?

Hi,

Yes I have the same issue, thanks for the solution BTW.

Hi,

I had the same problem and tried various relative paths in Settings → CI/CD → Token Access → Allow access to this project with a CI_JOB_TOKEN
You have to drop the https://gitlab.com/
for instance if you want to add https://gitlab.com/projetct/main_repo/git_repo
you have to add : projetct/main_repo/git_repo

Hope it helps.

Same here. My project stopped building a few days ago after I added a new submodule. On the contrary, all the submodules created at earlier times work well without additional configuration.

Update:
I have 3 projects, A, B, and C. B includes C as a submodule and A includes B, visually, it’s A->B->C.
I’ve already added A and B on C’s CI_JOB_TOKEN whitelist, but it still fails when building A, warning that C is not accessible. Any ideas?

Is there a setting to make this default allowed for a group? We add our internal libraries as submodules and to have to set this manually for every new lib module does not make any sense.