-
Bug
-
Resolution: Unresolved
-
Minor
-
None
-
Jenkins ver. 2.121.1, Git Plugin 3.9.1
It is my opinion is that when the "Disable submodules processing" is set the git fetch should have the `--no-recurse-submodules` option. Here is why:
We have a multibranch pipeline: which we are using for a git repo that has a number of submodules.
Due to security reasons, we do not give Jenkins permission to all the submodules via one ssh key. As such we load each submodule separately in the Jenkinsfile with the individual ssh key. This works great.
However, when we push a different commit to one of the submodules Jenkins always fails the first time that it runs that job. With this error:
/opt/bitnami/git/bin/git fetch --no-tags --progress git@github.com:repo/repo.git +refs/heads/*:refs/remotes/origin/* ERROR: Error fetching remote repo 'origin' hudson.plugins.git.GitException: Failed to fetch from git@github.com:repo/repo.git at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:888) at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1155) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1186) at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:113) at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:85) at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:75) at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1$1.call(AbstractSynchronousNonBlockingStepExecution.java:47) at hudson.security.ACL.impersonate(ACL.java:290) at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1.run(AbstractSynchronousNonBlockingStepExecution.java:44) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) Caused by: hudson.plugins.git.GitException: Command "/opt/bitnami/git/bin/git fetch --no-tags --progress git@github.com:repo/repo.git +refs/heads/*:refs/remotes/origin/*" returned status code 1:
As you can see this is an error with the git command fetch. It would seem that when one of the submodules has a change in the commit the fetch will do a recursive fetch. You can see that this is the default behaviour.. As such due to the lack of permissions that the key has for the submodules it fails. This is easily solved with the addition `--no-recurse-submodules` to the fetch command.
My opinion is that when the "Disable submodules processing" is set the git fetch should have the `--no-recurse-submodules` option. As such solving the problems described above.
+1 We are experiencing the same issue, although we don't use different SSH keys for each submodule.
We are using a GitHub organization which under the hood uses a token (basic http auth) to authenticate to GitHub when pulling. Our submodules are referenced using SSH, so this causes our pipelines to fail as well the first time.
benjamincerigo - have you made any progress on finding a workaround for your issue?