I'm running into this too. This is a huge regression from where the plugin was at. It's like this plugin wasn't tested before going live.

I think this is a git-client issue.

I'm not enough of a git guru to understand exactly what is happening here, but I believe I am being bitten by this issue. Cannot get any builds working

Does anyone have a workaround?

The workaround is to downgrade the git-plugin and git-client to the previous revision. I have to ask, why is the submodule update being done like this anyway? What was wrong with 'git submodule update --init'?

I can confirm this issue. It happened to us after the update of the git-plugin to version 3.0.0. 'git submodule update --init' always worked fine for us.

This is the error we are getting:

> C:\Program Files\Git\bin\git.exe submodule update --init --recursive old_path/to/sub
FATAL: Command "C:\Program Files\Git\bin\git.exe submodule update --init --recursive old_path/to/sub" returned status code 1:
stdout: 
stderr: error: pathspec 'old_path/to/sub' did not match any file(s) known to git.

hudson.plugins.git.GitException: Command "C:\Program Files\Git\bin\git.exe submodule update --init --recursive old_path/to/sub" returned status code 1:
stdout: 
stderr: error: pathspec 'old_path/to/sub' did not match any file(s) known to git.

	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1745)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1489)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:64)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$7.execute(CliGitAPIImpl.java:1032)
	at hudson.plugins.git.extensions.impl.SubmoduleOption.onCheckoutCompleted(SubmoduleOption.java:96)
	at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1137)
	at hudson.scm.SCM.checkout(SCM.java:495)
	at hudson.model.AbstractProject.checkout(AbstractProject.java:1278)
	at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:604)
	at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
	at hudson.model.Run.execute(Run.java:1728)
	at hudson.matrix.MatrixBuild.run(MatrixBuild.java:313)
	at hudson.model.ResourceController.execute(ResourceController.java:98)
	at hudson.model.Executor.run(Executor.java:404)

One thing to note: it uses old_path/to/sub instead of the actual new path. In .gitmodules, "old_path/to/sub" is just still the name of the submodule, so it tries to use the name instead of the actually configured submodule path.

Hi,

Please can i know is there any other work around to fix this issue

"stderr: error: pathspec 'ProjectA/testrepo' did not match any file(s) known to git."

This is really blocking our all builds.

As of now we are wiping out our workspace to ignore this error every time.

Thanks.

You can run "git submodule deinit" on the repo on your jenkins.

We have checked this option "Recursively update submodules" in job configuration page.

Where we have to mention the command "git submodule deinit" please can you correct me.

In my experience, running git submodule deinit . (for example as a pre-scm-build-step) does not work. What works for me:

• remove advanced submodule behavior
• git submodule deinit . as pre-scm build-step (this is optional, might not be necessary)
• git submodule update --init as first build step after checkout

> It's like this plugin wasn't tested before going live

Indeed.

Fixed in git client plugin 2.2.0, released 2 Jan 2017

Happening again in 2.2.1. I downgraded all the plugins and now it's working again.

Try cloning git@github.com:bbcarchdev/acropolis.git with enabled recursive in jenkins.

Error message

 > git config --get submodule.twine-anansi-bridge/m4.url # timeout=10
FATAL: Command "git config --get submodule.twine-anansi-bridge/m4.url" returned status code 1:
stdout: 
stderr: 
hudson.plugins.git.GitException: Command "git config --get submodule.twine-anansi-bridge/m4.url" returned status code 1:
stdout: 
stderr: 
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1784)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1757)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1753)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1409)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1421)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getSubmoduleUrl(CliGitAPIImpl.java:1091)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$7.execute(CliGitAPIImpl.java:1017)
	at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:152)
	at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:145)
	at hudson.remoting.UserRequest.perform(UserRequest.java:153)
	at hudson.remoting.UserRequest.perform(UserRequest.java:50)
	at hudson.remoting.Request$2.run(Request.java:336)
	at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
	at ......remote call to centos7_slave (i-0c8cc1000943d412e)(Native Method)
	at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1537)
	at hudson.remoting.UserResponse.retrieve(UserRequest.java:253)
	at hudson.remoting.Channel.call(Channel.java:822)
	at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:145)
	at sun.reflect.GeneratedMethodAccessor151.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:131)
	at com.sun.proxy.$Proxy65.execute(Unknown Source)
	at hudson.plugins.git.extensions.impl.SubmoduleOption.onCheckoutCompleted(SubmoduleOption.java:90)
	at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1141)
	at hudson.scm.SCM.checkout(SCM.java:496)
	at hudson.model.AbstractProject.checkout(AbstractProject.java:1278)
	at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:604)
	at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
	at hudson.model.Run.execute(Run.java:1728)
	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
	at hudson.model.ResourceController.execute(ResourceController.java:98)
	at hudson.model.Executor.run(Executor.java:405)
Finished: FAILURE

Still happening in git plugin 3.1.0 with git-client 2.3.0

git config --get-regexp is referencing the committed .gitmodules config file, but then git config --get is not.

If the reference is present in the repo, but not locally, it fails with status code 1 such as below.

Adding -f .gitmodules to the second command as well would work.

 > git submodule init # timeout=10
 > git config -f .gitmodules --get-regexp ^submodule\.(.*)\.url # timeout=10
 > git config --get submodule.rake-tasks.url # timeout=10
FATAL: Command "git config --get submodule.rake-tasks.url" returned status code 1:
stdout: 
stderr: 
hudson.plugins.git.GitException: Command "git config --get submodule.rake-tasks.url" returned status code 1:
stdout: 
stderr: 
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1793)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1766)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1762)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1409)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1421)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getSubmoduleUrl(CliGitAPIImpl.java:1091)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$7.execute(CliGitAPIImpl.java:1017)
	at hudson.plugins.git.extensions.impl.SubmoduleOption.onCheckoutCompleted(SubmoduleOption.java:102)
	at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1156)
	at hudson.scm.SCM.checkout(SCM.java:496)
	at hudson.model.AbstractProject.checkout(AbstractProject.java:1278)
	at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:604)
	at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
	at hudson.model.Run.execute(Run.java:1728)
	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
	at hudson.model.ResourceController.execute(ResourceController.java:98)
	at hudson.model.Executor.run(Executor.java:405)

Is also failing for version "git plugin" 3.2.0 and "git client plugin" 2.4.1

 > git config --get submodule.SUBMODULE # timeout=10
FATAL: Command "git config --get submodule.SUBMODULE.url" returned status code 1:
stdout: 
stderr: 
hudson.plugins.git.GitException: Command "git config --get submodule.SUBMODULE.url" returned status code 1:
stdout: 
stderr: 
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1799)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1772)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1768)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1415)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1427)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getSubmoduleUrl(CliGitAPIImpl.java:1092)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$7.execute(CliGitAPIImpl.java:1018)
	at hudson.plugins.git.extensions.impl.SubmoduleOption.onCheckoutCompleted(SubmoduleOption.java:102)
	at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1170)
	at hudson.scm.SCM.checkout(SCM.java:496)
	at hudson.model.AbstractProject.checkout(AbstractProject.java:1278)
	at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:604)
	at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
	at hudson.model.Run.execute(Run.java:1728)
	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
	at hudson.model.ResourceController.execute(ResourceController.java:98)
	at hudson.model.Executor.run(Executor.java:405)

Hi there,

is there any workaround for this?

We just refactored a project to switch from "multiple SCM" to submodules and never considered that Jenkins would choke on this.

Currently, the project does not build at all.

Thanks in advance.

One work around is to perform your own submodule commands from your build scripts, rather than relying on the git plugin to perform those submodule commands.

Another workaround is to use the "wipe workspace" additional behaviour in the git plugin so that it starts each build with a fresh workspace.  See the earlier comment

Another workaround is to use the pipeline deleteDir() method to wipe the workspace before the checkout step.

For the time being I have disabled submodules in the main project and used "multiple SCM" to checkout the submodules where needed.

I'll keep watching the thread for a fix.

Hi,

This is also a stopper for us, since most of our repos are submoduled, where we currently can't get past Git plugin 2.3.4 and Git Client plugin 1.19.7, which is stopping a lot of other plugins to be updated, such as the Job DSL plugin just to name one. We have somewhere ~1600 Jenkins jobs, and not all of them DSL'ed, so it's quite a work to change them to use regular git commands from a shell.

A prioritization on this one would be greatly appreciated.

Thanks in advance!

I've constructed a public test which shows the problem and mirrored the same test into a private repository (with authenticated submodule access).

Hi Mark,

unfortunately, in my case this does not help.

I do have submodules in private repose and others in public repos.

I have wipped out the workspace.

I have used "Advance submodule configuration" and checked to recurse into submodules and use parent module credentials, but it fails on the first submodule that happen to be public.

 
The error is
FATAL: Command "git config --get submodule.MySubModule.url" returned status code 1

I am happy to try other workarounds.

jmcazaux if wipe workspace does not work, then it is likely that any fix I make will also not work. My goal with the change will be to assure that a repository cloned in a newly created job (with submodules enabled) looks the same as a repository which has been used previously but the submodule definitions in the repository have changed.

Can you provide detailed instructions to show (in a public repository) the case that is failing for you?

When you say "I have wiped out the workspace", that doesn't sound like you enabled the "Additional Behaviours" to "Wipe workspace". The work around requires that you enable that additional behavior. It is not enough to interactively wipe out the workspace.

The error reported above:

> FATAL: Command "git config --get submodule.MySubModule.url" returned status code 1

Occurs for me whenever you have nested submodules. Consider a scenario in which repo A contains submodule B, which contains submodule C.

If "Advanced submodule behaviour" with "Recursively update submodules" is not enabled, Jenkins will clone A, checkout/clone B, and fail to initialise/clone C. This is probably expected behaviour.

If you enable "Recursively update submodules", you get the erro:

> FATAL: Command "git config --get submodule.C.url" returned status code 1

Here's some complete log output of this scenario, with repo names changed to A, B, and C to fit my example scenario:

[0:native:Debug] Cloning the remote Git repository
[0:native:Debug] Cloning with configured refspecs honoured and without tags
[0:native:Debug] Cloning repository A
[0:native:Debug] > git init /workspace/A_master_10/source # timeout=10
[0:native:Debug] Fetching upstream changes from A
[0:native:Debug] > git --version # timeout=10
[0:native:Debug] using GIT_SSH to set credentials Jenkins GitHub SSH key
[0:native:Debug] > git fetch --no-tags --progress A+refs/heads/master:refs/remotes/origin/master
[0:native:Debug] > git config remote.origin.url A # timeout=10
[0:native:Debug] > git config --add remote.origin.fetch +refs/heads/master:refs/remotes/origin/master # timeout=10
[0:native:Debug] > git config remote.origin.url A # timeout=10
[0:native:Debug] Fetching without tags
[0:native:Debug] Fetching upstream changes from A
[0:native:Debug] using GIT_SSH to set credentials Jenkins GitHub SSH key
[0:native:Debug] > git fetch --no-tags --progress A+refs/heads/master:refs/remotes/origin/master
[0:native:Debug] Checking out Revision 7b8f0cd431c42d62bd76ec23e879a95ea1f2e01f (master)
[0:native:Debug] Commit message: "Bump B"
[0:native:Debug] Enabling Git LFS pull
[0:native:Debug] > git config core.sparsecheckout # timeout=10
[0:native:Debug] > git checkout -f 7b8f0cd431c42d62bd76ec23e879a95ea1f2e01f
[0:native:Debug] > git config --get remote.origin.url # timeout=10
[0:native:Debug] using GIT_SSH to set credentials Jenkins GitHub SSH key
[0:native:Debug] > git lfs pull origin
[0:native:Debug] > git rev-list 7b8f0cd431c42d62bd76ec23e879a95ea1f2e01f # timeout=10
[0:native:Debug] > git remote # timeout=10
[0:native:Debug] > git submodule init # timeout=10
[0:native:Debug] > git submodule sync # timeout=10
[0:native:Debug] > git config --get remote.origin.url # timeout=10
[0:native:Debug] > git submodule init # timeout=10
[0:native:Debug] > git config -f .gitmodules --get-regexp ^submodule\.(.*)\.url # timeout=10
[0:native:Debug] > git config --get submodule.B.url # timeout=10
[0:native:Debug] > git remote # timeout=10
[0:native:Debug] > git config --get remote.origin.url # timeout=10
[0:native:Debug] > git config -f .gitmodules --get submodule.B.path # timeout=10
[0:native:Debug] using GIT_SSH to set credentials Jenkins GitHub SSH key
[0:native:Debug] > git submodule update --init --recursive B
[0:native:Debug] > git config --get submodule.C.url # timeout=10

That last command fails, because it is being executed inside A. The submodule.C.url config value exists only in B, not in A, so this fails (the similar command earlier for B works, however).

This seems to be the core of the bug: you're not changing directory when executing this config --get command, causing this url-query step to fail when recursive submodule checkout is enabled.

Unfortunately, I ran into the exact issue as described by Chris Kitching. I tried to disable the recursive option of checking out, but that didn't work either - the plugin still tries to clone recursively.

Won't be fixed in the git plugin.

Google Summer of Code 2021 is implementing git credentials binding for sh, bat, and powershell so that jobs can perform exactly the type of submodule update that they prefer. Rather than modify the already complicated git plugin submodule implementation, that will allow users to call command line git with the exact arguments they want for their submodule update.

See https://github.com/jenkinsci/git-plugin/pull/1104 for latest status

I have the same problem migrating project to submodules.

If you won't fix or provide a working submodule update feature, it is a nonsense to provide this feature.