Mark Waite added a comment - 2020-10-10 23:07 - edited Is the submodule defined to use the same protocol and same credentials as the parent repository? Authenticated submodule checkout requires that the submodule must be accessed using the same protocol and same credentials as the parent repository. If the original repository is fetched with https (as it appears in your case), then the submodule reference in that branch of the original repository must refer to the submodule using https protocol, not using ssh protocol. Is the checkout step defined to use the parent credentials ( parentCredentials: true ) when performing the submodule checkout? In my acceptance test job, I see the following definition of the checkout step: def branch='JENKINS-38860' node('git-1.8+') { stage('Checkout') { checkout([$class: 'GitSCM', userRemoteConfigs: [[url: 'git@github.com:MarkEWaite/jenkins-bugs-private.git', credentialsId: 'MarkEWaite-github-rsa-private-key', name: 'bugs-private-origin', refspec: "+refs/heads/${branch}:refs/remotes/bugs-private-origin/${branch}", ]], branches: [[name: branch]], extensions: [ [$class: 'SubmoduleOption', disableSubmodules: false, parentCredentials: true, recursiveSubmodules: true, reference: '/var/lib/git/mwaite/bugs/jenkins-bugs-private.git', trackingSubmodules: false], ], gitTool: 'Default', /* Submodule authentication not supported in JGit */ ]) } } The command line git version 2.26.2 has full support for submodules. While investigating to see if there is an issue here, I ran an acceptance test job on agents with Git 2.26.2 (FreeBSD and OpenBSD in my test cases). Those jobs were all successful at submodule checkout. If it helps, you're welcome to refer to the public version of my acceptance test job for details that I know are working in my acceptance test environment. I have a similar job that includes credentials and uses https to access a private GitHub repository.

F M added a comment - 2020-10-11 07:13 Thanks for looking into it.Any idea where to look at next (your test script works for me; see below)? Note that the branch I try to checkout/test is the only one with submodules in that repo yet. I updated the Docker FROM jenkins/jenkins:2.260-alpine and and also downgraded with an older version (but got the same issues). I made sure to use the git:// scheme (the way submodules are referenced in .gitmodules) and used my own SSH credentials (but got the same issue). I used your test script pipeline with some ls -al to verify to get the expected files. This passes! I see in this console logging multiple times: using GIT_SSH to set credentials Access github repo - me But I don't see this when using the multibranch pipeline at the time it fails I think that's the cause. For completeness I added the test script's output (the actual checkout of git submodule update --init --recursive submodule is removed): Started by user admin Running in Durability level: MAX_SURVIVABILITY [Pipeline] Start of Pipeline [Pipeline] node Running on Jenkins in / var /jenkins_home/workspace/simple [Pipeline] { [Pipeline] stage [Pipeline] { (Checkout) [Pipeline] checkout The recommended git tool is: git using credential 1d634ef3-2d37-4386-a736-4008b2d118db > git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository > git config remote.checkout_test.url git@github. private .com:Dep/project.git # timeout=10 Fetching upstream changes from git@github. private .com:Dep/project.git > git --version # timeout=10 > git --version # 'git version 2.26.2' using GIT_SSH to set credentials Access github repo - me > git fetch --tags --force --progress -- git@github. private .com:Dep/project.git +refs/heads/dep/add_submodule:refs/remotes/checkout_test/dep/add_submodule # timeout=10 > git rev-parse refs/remotes/checkout_test/dep/add_submodule^{commit} # timeout=10 > git rev-parse dep/add_submodule^{commit} # timeout=10 Checking out Revision 463f3d60c604e489e847e20f880942f4cdf68b0b (refs/remotes/checkout_test/dep/add_submodule) > git config core.sparsecheckout # timeout=10 > git checkout -f 463f3d60c604e489e847e20f880942f4cdf68b0b # timeout=10 Commit message: "test directory is gone" > git rev-list --no-walk 463f3d60c604e489e847e20f880942f4cdf68b0b # timeout=10 > git remote # timeout=10 > git submodule init # timeout=10 > git submodule sync # timeout=10 > git config --get remote.bugs- private -origin.url # timeout=10 > git submodule init # timeout=10 > git config -f .gitmodules --get-regexp ^submodule\.(.+)\.url # timeout=10 > git config --get submodule.submodule.url # timeout=10 > git remote # timeout=10 > git config --get remote.bugs- private -origin.url # timeout=10 > git config -f .gitmodules --get submodule.submodule.path # timeout=10 using GIT_SSH to set credentials Access github repo - me > git submodule update --init --recursive submodule # timeout=10 [Pipeline] } [Pipeline] // stage [Pipeline] sh + ls -al total 124 ... lines cut here ... [Pipeline] sh + ls -al submodule total 104 ... lines cut here ... [Pipeline] } [Pipeline] // node [Pipeline] End of Pipeline Finished: SUCCESSREST API      

Mark Waite added a comment - 2020-10-11 11:43 The logfile reports that you are using git@github.private.com:Dep/project.git as the repository URL. That uses ssh protocol and requires an ssh private key to authenticate. If you retrieve the initial repository with ssh, then the submodule must be defined to use ssh as well. One way to check that you're using consistent protocol for parent repository and for the submodules is: $ git remote -v origin git@github.com:MarkEWaite/parent-private.git (fetch) origin git@github.com:MarkEWaite/parent-private.git (push) $ git submodule foreach git remote -v Entering 'test-submodules/JENKINS-43022-325' origin git@github.com:MarkEWaite/submodule-private.git (fetch) origin git@github.com:MarkEWaite/submodule-private.git (push) In that output, you see that the submodule uses git@github.com just as the parent repository does.

F M added a comment - 2020-10-11 13:03 I'm sorry, I found the mistake to be on my side. The multibranch is handling the credentials correctly.