[JIRA] (JENKINS-38860) Git plugin using local config to update submodules

10 views
Skip to first unread message

bdanilovich@preemptsecurity.com (JIRA)

unread,
Oct 10, 2016, 8:56:01 AM10/10/16
to jenkinsc...@googlegroups.com
Boris Danilovich created an issue
 
Jenkins / Bug JENKINS-38860
Git plugin using local config to update submodules
Issue Type: Bug Bug
Assignee: Mark Waite
Components: git-plugin
Created: 2016/Oct/10 12:55 PM
Environment: Jenkins v2.6, Git plugin version 3.0.0
Priority: Major Major
Reporter: Boris Danilovich

In order to get all of the submodules, the git plugin looks in the local configuration file:

 > git config --get-regexp ^submodule # timeout=10
 > git config --get submodule.externals/jzmq.url # timeout=10
 > git submodule update --remote externals/jzmq
 > git config --get submodule.protobuf-java-format.url # timeout=10
 > git submodule update --remote protobuf-java-format
FATAL: Command "git submodule update --remote protobuf-java-format" returned status code 1:
stdout: 
stderr: error: pathspec 'protobuf-java-format' did not match any file(s) known to git.

However, the .git/config file is local per repository, and old entries and sections do not get overriden. Therefore, when a submodule is no longer in use or has moved, the old configuration can cause an error. Anyway, the local configuration is not part of the remote repository, which is the correct clean repo which is the exclusive authority on git configs.

A possible solution would be to call deninit in order to remove the old configuration.

git submodule deinit
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
Atlassian logo

mark.earl.waite@gmail.com (JIRA)

unread,
Oct 10, 2016, 9:37:01 AM10/10/16
to jenkinsc...@googlegroups.com
Mark Waite assigned an issue to Unassigned
Change By: Mark Waite
Assignee: Mark Waite

kaveh@vaghefi.org (JIRA)

unread,
Oct 11, 2016, 2:33:01 PM10/11/16
to jenkinsc...@googlegroups.com
Kaveh Vaghefi commented on Bug JENKINS-38860
 
Re: Git plugin using local config to update submodules

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

kaveh@vaghefi.org (JIRA)

unread,
Oct 11, 2016, 2:34:01 PM10/11/16
to jenkinsc...@googlegroups.com
Kaveh Vaghefi updated an issue
 
Change By: Kaveh Vaghefi
Priority: Major Blocker

kaveh@vaghefi.org (JIRA)

unread,
Oct 11, 2016, 2:39:02 PM10/11/16
to jenkinsc...@googlegroups.com
Kaveh Vaghefi edited a comment on Bug JENKINS-38860
 
Re: Git plugin using local config to update submodules
I'm running into this too.  This is a huge regression from where the plugin was at.  It's like it this plugin wasn't tested before going live.

kaveh@vaghefi.org (JIRA)

unread,
Oct 11, 2016, 3:39:01 PM10/11/16
to jenkinsc...@googlegroups.com
Kaveh Vaghefi updated an issue
Change By: Kaveh Vaghefi
Environment: Jenkins v2.6, Git plugin version 3.0.0 , git-client 2.0.0

kaveh@vaghefi.org (JIRA)

unread,
Oct 11, 2016, 3:39:06 PM10/11/16
to jenkinsc...@googlegroups.com
Kaveh Vaghefi edited a comment on Bug JENKINS-38860
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.

lars@foldspace.nu (JIRA)

unread,
Oct 12, 2016, 3:51:01 AM10/12/16
to jenkinsc...@googlegroups.com

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?

kaveh@vaghefi.org (JIRA)

unread,
Oct 12, 2016, 1:20:01 PM10/12/16
to jenkinsc...@googlegroups.com

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'?

roman.karlstetter@gmail.com (JIRA)

unread,
Nov 22, 2016, 7:04:03 AM11/22/16
to jenkinsc...@googlegroups.com

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.

roman.karlstetter@gmail.com (JIRA)

unread,
Nov 22, 2016, 7:10:02 AM11/22/16
to jenkinsc...@googlegroups.com
Roman Karlstetter edited a comment on Bug JENKINS-38860
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 --recursiveold_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 submodules, so it tries to use the name instead of the actually configured submodule path.

roman.karlstetter@gmail.com (JIRA)

unread,
Nov 22, 2016, 7:11:02 AM11/22/16
to jenkinsc...@googlegroups.com
Roman Karlstetter edited a comment on Bug JENKINS-38860
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:
{ { code:shell}
> 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 --recursiveold_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)

{code } }

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 submodules, so it tries to use the name instead of the actually configured submodule path.

roman.karlstetter@gmail.com (JIRA)

unread,
Nov 22, 2016, 7:11:03 AM11/22/16
to jenkinsc...@googlegroups.com
Roman Karlstetter edited a comment on Bug JENKINS-38860
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 --recursiveold_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 submodules, so it tries to use the name instead of the actually configured submodule path.

roman.karlstetter@gmail.com (JIRA)

unread,
Nov 22, 2016, 7:12:02 AM11/22/16
to jenkinsc...@googlegroups.com
Roman Karlstetter edited a comment on Bug JENKINS-38860
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:

{code: shell none }

> 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 --recursiveold_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)
{code}


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 submodules, so it tries to use the name instead of the actually configured submodule path.

roman.karlstetter@gmail.com (JIRA)

unread,
Nov 22, 2016, 7:12:02 AM11/22/16
to jenkinsc...@googlegroups.com
Roman Karlstetter edited a comment on Bug JENKINS-38860
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:

{code:none}

> 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 -- recursiveold_path 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)
{code}

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 submodules, so it tries to use the name instead of the actually configured submodule path.

roman.karlstetter@gmail.com (JIRA)

unread,
Nov 22, 2016, 7:13:02 AM11/22/16
to jenkinsc...@googlegroups.com
Roman Karlstetter edited a comment on Bug JENKINS-38860
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:

{code:none}
> 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)
{code}

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 submodules submodule , so it tries to use the name instead of the actually configured submodule path.

Senthilkumar.Palanisamy@in.bosch.com (JIRA)

unread,
Nov 23, 2016, 7:02:01 AM11/23/16
to jenkinsc...@googlegroups.com

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.

bdanilovich@preemptsecurity.com (JIRA)

unread,
Nov 23, 2016, 10:19:03 AM11/23/16
to jenkinsc...@googlegroups.com

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

Senthilkumar.Palanisamy@in.bosch.com (JIRA)

unread,
Nov 24, 2016, 7:31:04 AM11/24/16
to jenkinsc...@googlegroups.com

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.

roman.karlstetter@gmail.com (JIRA)

unread,
Nov 24, 2016, 10:50:03 AM11/24/16
to jenkinsc...@googlegroups.com

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

sam@elegantchaos.com (JIRA)

unread,
Dec 2, 2016, 12:13:01 PM12/2/16
to jenkinsc...@googlegroups.com

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

Indeed.

mark.earl.waite@gmail.com (JIRA)

unread,
Dec 18, 2016, 8:58:01 PM12/18/16
to jenkinsc...@googlegroups.com
Mark Waite assigned an issue to Mark Waite
 
Change By: Mark Waite
Assignee: Mark Waite

mark.earl.waite@gmail.com (JIRA)

unread,
Jan 2, 2017, 7:03:04 PM1/2/17
to jenkinsc...@googlegroups.com
Mark Waite commented on Bug JENKINS-38860
 
Re: Git plugin using local config to update submodules

Fixed in git client plugin 2.2.0, released 2 Jan 2017

mark.earl.waite@gmail.com (JIRA)

unread,
Jan 2, 2017, 7:03:05 PM1/2/17
to jenkinsc...@googlegroups.com
Mark Waite resolved as Fixed
 
Change By: Mark Waite
Status: Open Resolved
Resolution: Fixed

rackeby@hotmail.com (JIRA)

unread,
Feb 6, 2017, 3:40:03 PM2/6/17
to jenkinsc...@googlegroups.com
Pierre Larsson reopened an issue
 

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

Try cloning g...@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
Change By: Pierre Larsson
Resolution: Fixed
Status: Resolved Reopened

rackeby@hotmail.com (JIRA)

unread,
Feb 6, 2017, 3:40:05 PM2/6/17
to jenkinsc...@googlegroups.com
Pierre Larsson updated an issue
Change By: Pierre Larsson
Environment: Jenkins v2.6, Git plugin version 3.0.0, git-client 2. 0 2 . 0 1

kboz@java.net (JIRA)

unread,
Mar 19, 2017, 6:20:01 PM3/19/17
to jenkinsc...@googlegroups.com
kboz commented on Bug JENKINS-38860
 
Re: Git plugin using local config to update submodules

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)

 
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
Atlassian logo

rafal+jenkins@rjanicki.eu (JIRA)

unread,
Apr 18, 2018, 12:31:02 PM4/18/18
to jenkinsc...@googlegroups.com

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.

mark.earl.waite@gmail.com (JIRA)

unread,
Dec 8, 2018, 12:51:03 PM12/8/18
to jenkinsc...@googlegroups.com
Change By: Mark Waite
Status: Reopened Open
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

mark.earl.waite@gmail.com (JIRA)

unread,
Feb 15, 2019, 9:20:02 PM2/15/19
to jenkinsc...@googlegroups.com
Mark Waite assigned an issue to Unassigned
Change By: Mark Waite
Assignee: Mark Waite
Reply all
Reply to author
Forward
0 new messages