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

3 Likes

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

1 Like

Hi,

I got the same issues and tried to add the access in the P2 project parameter, in SettingsCI/CDToken AccessAllow 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 ?

4 Likes

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 SettingsCI/CDToken AccessAllow 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.

1 Like

Job or other tokens have little to do here since they are not something used during the submodule cloning stage of a CI job. Of course, for external repos that require authentication, the runner needs to have added the public SSH key of the remote in order to be able to use that submodule. This does not apply for public repos, which can be accessed via HTTPS.

The documentation of GitLab regarding this is still absent and I’m probably not the only one who wasted a decent amount of time looking for a solution. “Limit access to” is the way to go. Just don’t forget to add the project that uses the submoduled repo to the whitelist of the submoduled repo and not the other way around. Especially for people, who used the older “Limit access from” this can happen quite often.

I made all what I found, the only thing I am not configure yet is the ssh key. But the access token not change anything. Here the error I received. The setting of Job token permissions is done.

Updating/initializing submodules recursively with git depth set to 20…
Submodule ‘shipmate’ (https://gitlab.com/logistec1/shipmate.git) registered for path ‘shipmate’
Synchronizing submodule url for ‘shipmate’
Cloning into ‘/builds/logistec1/logistec-app/inv_approv/shipmate’…
fatal: could not read Username for 'https://gitlab.com’: No such device or address
fatal: clone of ‘https://gitlab.com/logistec1/shipmate.git’ into submodule path ‘/builds/logistec1/logistec-app/inv_approv/shipmate’ failed
Failed to clone ‘shipmate’. Retry scheduled