Runner 17.5 seems to break cross project submodule authentication with job tokens.
When reverting back to runner 17.4.1 it works.
Cloning into '/builds/example/example/git/example/example_data/example_data'...fatal: could not read Username for 'https://example.com': No such device or addressfatal: clone of 'https://example.com/example/example_data/example_data.git' into submodule path '/builds/example/example/git/example/example_data/example_data' failedFailed to clone 'example_data/example_data'. Retry scheduled
Steps to reproduce
Have a submodule in a project from the same gitlab domain. Allow job tokes access. -> Submodule cannot be updated on the gitlab runner 17.5
.gitlab-ci.yml
Add the job definition that is failing here
Actual behavior
Runner 17.5 cannot authenticate with job tokens to update a submodule from the same domain.
Expected behavior
Runner 17.5 can authenticate with a job token to update a submodule from the same domain.
Relevant logs and/or screenshots
job log
Add the job log
Environment description
We install gitlab runner from debian packages on Ubuntu 20.04
Samuel Bachmannchanged title from Runner 17.5 breaks cross project submodule authentication to Runner 17.5 breaks cross project submodule authentication with job token
changed title from Runner 17.5 breaks cross project submodule authentication to Runner 17.5 breaks cross project submodule authentication with job token
GitLab Premium customer here.
Can confirm the issue, all of our pipelines with submodules are failing left and right, most of our projects are not capable of building because of this issue. We have to revert back to 17.4 now.
Same for me with the GitLab Community Edition. Afer Update to 17.5. Revert to the prior gitlab-runner version 17.4.1-1 and we are bacl in working progress.
Samuel Bachmannchanged the descriptionCompare with previous version
So was this expected with !5031 (merged) or is this just a workaround and it should actually work with FF_GIT_URLS_WITHOUT_TOKENS: 1?
It should actually work with FF_GIT_URLS_WITHOUT_TOKENS: 1, but doesn't; so this is clearly a .
The workaround is to set FF_GIT_URLS_WITHOUT_TOKENS: 0, but we are working on a fix for that, and might switch the default for this FF until this fix is ready.
if that helps, our submodules use relative paths for internal private projects (I guess https)
It sure helps! Thanks!
Could you maybe share your .gitmodules file from the repo in question?
I can confirm this too; all of our runners with gitlab/gitlab-runner:latest image fail to pull submodules using built-in authentication ($CI_JOB_TOKEN?).
Pinning to v17.4.1 resolves the issue.
Getting source from Git repository 00:01Fetching changes with git depth set to 50...Initialized empty Git repository in /builds/group/project/.git/Created fresh repository.Checking out dcb10d2f as detached HEAD (ref is develop)...Updating/initializing submodules recursively with git depth set to 50...Submodule 'path/to/submodule' (https://self-hosted.gitlab.example/submodule-group/submodule.git) registered for path 'path/to/submodule'Synchronizing submodule url for 'path/to/submodule'Cloning into '/builds/group/project/path/to/submodule'...fatal: could not read Username for 'https://self-hosted.gitlab.example': No such device or addressfatal: clone of 'https://self-hosted.gitlab.example/submodule-group/submodule.git' into submodule path '/builds/group/project/path/to/submodule' failedFailed to clone 'path/to/submodule'. Retry scheduledCloning into '/builds/group/project/path/to/submodule'...fatal: could not read Username for 'https://self-hosted.gitlab.example': No such device or addressfatal: clone of 'https://self-hosted.gitlab.example/submodule-group/submodule.git' into submodule path '/builds/group/project/path/to/submodule' failedFailed to clone 'path/to/submodule' a second time, aborting
Succeeding:
Getting source from Git repository 00:02Fetching changes with git depth set to 50...Initialized empty Git repository in /builds/group/project/.git/Created fresh repository.Checking out dcb10d2f as detached HEAD (ref is develop)...Updating/initializing submodules recursively with git depth set to 50...Submodule 'path/to/submodule' (https://gitlab-ci-token:[MASKED]@self-hosted.gitlab.example/submodule-group/submodule.git) registered for path 'path/to/submodule'Synchronizing submodule url for 'path/to/submodule'Cloning into '/builds/group/project/path/to/submodule'...From https://self-hosted.gitlab.example/submodule-group/submodule * branch b80479a0abb8f0a091bc1495b613d0c6dbca6324 -> FETCH_HEADSubmodule path 'path/to/submodule': checked out 'b80479a0abb8f0a091bc1495b613d0c6dbca6324'Updated submodulesSynchronizing submodule url for 'path/to/submodule'Entering 'path/to/submodule'Entering 'path/to/submodule'