[JIRA] (JENKINS-60875) branch index scan of multibranch pipeline job fails with hudson.plugins.git.GitException

20 views
Skip to first unread message

gerriet.reents@btc-ag.com (JIRA)

unread,
Jan 27, 2020, 8:31:02 AM1/27/20
to jenkinsc...@googlegroups.com
Gerriet Reents created an issue
 
Jenkins / Bug JENKINS-60875
branch index scan of multibranch pipeline job fails with hudson.plugins.git.GitException
Issue Type: Bug Bug
Assignee: Mark Waite
Components: git-client-plugin
Created: 2020-01-27 13:30
Environment: os: CentOS 7
jdk: openjdk-1.8.0.191
Jenkins version 2.210
git client: 3.0.0
Priority: Major Major
Reporter: Gerriet Reents

A multibranch pipeline jobs is configured for a git repo. Scanning the branch index ends with an excpetion from git client:

Mon Jan 27 09:21:00 CET 2020] Starting branch indexing...
 > git --version # timeout=10
using GIT_ASKPASS to set credentials User for XXX bitbucket instance
Setting http proxy: XXX.XXX.XXX.X:9090
 > git ls-remote https://bitbucket.xxx.yy/somewhat.git # timeout=10
ERROR: [Mon Jan 27 09:21:01 CET 2020] Could not update folder level actions from source <uuid ommited> 
hudson.plugins.git.GitException: Command "git ls-remote https://bitbucket.xxx.yy/somewhat.git" returned status code 128:
stdout: 
stderr: fatal: unable to access '.git/config': Permission denied

	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2372)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1985)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1885)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1876)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getRemoteReferences(CliGitAPIImpl.java:3228)
	at jenkins.plugins.git.AbstractGitSCMSource.retrieveActions(AbstractGitSCMSource.java:1141)
	at jenkins.scm.api.SCMSource.fetchActions(SCMSource.java:848)
	at jenkins.branch.MultiBranchProject.computeChildren(MultiBranchProject.java:598)
	at com.cloudbees.hudson.plugins.folder.computed.ComputedFolder.updateChildren(ComputedFolder.java:277)
	at com.cloudbees.hudson.plugins.folder.computed.FolderComputation.run(FolderComputation.java:164)
	at jenkins.branch.MultiBranchProject$BranchIndexing.run(MultiBranchProject.java:1032)
	at hudson.model.ResourceController.execute(ResourceController.java:97)
	at hudson.model.Executor.run(Executor.java:428)
[Mon Jan 27 09:21:01 CET 2020] Finished branch indexing. Indexing took 91 ms

It seems, that git client plugin tries to run the git ls-remote command somewhere, where the jenkins instance does not have write access to.

By looking into the code, I saw that

org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getRemoteReferences

does not define a workdir for the git command call and so the process default workdir is chosen.

The pwd of the java vm running jenkins is /

That would explain the problem.

Idea: Use java.io.tempdir to get a good workdir, if nothing else fits.
Add Comment Add Comment
 
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
Atlassian logo

gerriet.reents@btc-ag.com (JIRA)

unread,
Jan 27, 2020, 8:33:03 AM1/27/20
to jenkinsc...@googlegroups.com
Gerriet Reents updated an issue
Change By: Gerriet Reents
A multibranch pipeline jobs is configured for a git repo. Scanning the branch index ends with an excpetion from git client:
{code:java}

Mon Jan 27 09:21:00 CET 2020] Starting branch indexing...
> git --version # timeout=10
using GIT_ASKPASS to set credentials User for XXX bitbucket instance
Setting http proxy: XXX.XXX.XXX.X:9090
> git ls-remote https://bitbucket.xxx.yy/somewhat.git # timeout=10
ERROR: [Mon Jan 27 09:21:01 CET 2020] Could not update folder level actions from source <uuid ommited>
hudson.plugins.git.GitException: Command "git ls-remote https://bitbucket.xxx.yy/somewhat.git" returned status code 128:
stdout:
stderr: fatal: unable to access '.git/config': Permission denied

at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2372)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1985)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1885)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1876)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getRemoteReferences(CliGitAPIImpl.java:3228)
at jenkins.plugins.git.AbstractGitSCMSource.retrieveActions(AbstractGitSCMSource.java:1141)
at jenkins.scm.api.SCMSource.fetchActions(SCMSource.java:848)
at jenkins.branch.MultiBranchProject.computeChildren(MultiBranchProject.java:598)
at com.cloudbees.hudson.plugins.folder.computed.ComputedFolder.updateChildren(ComputedFolder.java:277)
at com.cloudbees.hudson.plugins.folder.computed.FolderComputation.run(FolderComputation.java:164)
at jenkins.branch.MultiBranchProject$BranchIndexing.run(MultiBranchProject.java:1032)
at hudson.model.ResourceController.execute(ResourceController.java:97)
at hudson.model.Executor.run(Executor.java:428)
[Mon Jan 27 09:21:01 CET 2020] Finished branch indexing. Indexing took 91 ms{code}

It seems, that git client plugin tries to run the {{git ls-remote}} command somewhere, where the jenkins instance does not have write access to.

By looking into the code, I saw that
{code:java}
org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getRemoteReferences
{code}

does not define a workdir for the git command call and so the process default workdir is chosen.

The pwd of the java vm running jenkins is {{/}}

That would explain the problem.

Idea: Use {{java.io. tempdir tmpdir }} to get a good workdir, if nothing else fits.

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

unread,
Jan 27, 2020, 11:25:03 AM1/27/20
to jenkinsc...@googlegroups.com
Mark Waite commented on Bug JENKINS-60875
 
Re: branch index scan of multibranch pipeline job fails with hudson.plugins.git.GitException

What version of command line git are you running on that computer? The git ls-remote command should not attempt to write to the .git/config file and should gracefully handle attempts to read from the file.

The issue mentions CentOS 7. The default version of command line git on CentOS 7 is git 1.8. That version of command line git is several years behind the current command line git 2.25.0.

As a work around, you could set the working directory of the process that starts Jenkins to the JENKINS_HOME directory before starting the Jenkins process.

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

unread,
Jan 27, 2020, 11:25:04 AM1/27/20
to jenkinsc...@googlegroups.com
Mark Waite assigned an issue to Unassigned
 
Change By: Mark Waite
Assignee: Mark Waite

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

unread,
Jan 27, 2020, 11:27:02 AM1/27/20
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on Bug JENKINS-60875
What version of command line git are you running on that computer?  The {{git ls-remote}} command should not attempt to write to the {{.git/config}} file and should gracefully handle attempts to read from the file.

The issue mentions CentOS 7.  The default version of command line git on CentOS 7 is git 1.8.  That version of command line git is several years behind the current command line git 2.25.0.

As a work around, you could set the working directory of the process that starts Jenkins to the JENKINS_HOME directory before starting the Jenkins process.


Scanning the remote repository with {{git ls-remote}} is generally expected to be performed from a local copy of the repository.  Setting the working directory inside the {{getRemoteReferences}} call seems like that risks overriding the working directory as set by other processes.

gerriet.reents@btc-ag.com (JIRA)

unread,
Jan 27, 2020, 11:52:03 AM1/27/20
to jenkinsc...@googlegroups.com

Thanks for your quick reply!

Indeed, local git version is 1.8.3.1. I will try to change the working directory at startup of jenkins.

But maybe, there is an issue with multibranch jobs in general, here. When scanning for branches, there seems to be no local copy of the repository!?

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

unread,
Jan 27, 2020, 11:56:03 AM1/27/20
to jenkinsc...@googlegroups.com

Branch source plugins that use a REST API call to request the changes from the remote repository do not need a local repository. Since you report that you're using Bitbucket, I assume you're using the Bitbucket branch source plugin. I thought it was modeled after the GitHub and Gitea plugins which use REST API calls rather than using git ls-remote.

If you're using the git plugin to provide the branch source (git as branch source provider instead of Bitbucket), then you'll usually find the cached repositories in the $JENKINS_HOME/caches directory.

gerriet.reents@btc-ag.com (JIRA)

unread,
Jan 27, 2020, 12:06:02 PM1/27/20
to jenkinsc...@googlegroups.com

I haved used the git plugin. Now i have tried the Bitbucket branch source plugin. There everything works fine!

Thanks for the hint!

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

unread,
Jan 27, 2020, 1:16:02 PM1/27/20
to jenkinsc...@googlegroups.com
Mark Waite updated an issue
 
Change By: Mark Waite
Priority: Major Minor

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

unread,
Jan 27, 2020, 1:17:03 PM1/27/20
to jenkinsc...@googlegroups.com
Mark Waite updated an issue
Change By: Mark Waite
Component/s: git-plugin
Component/s: git-client-plugin

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

unread,
Jan 27, 2020, 1:23:02 PM1/27/20
to jenkinsc...@googlegroups.com
Mark Waite commented on Bug JENKINS-60875
 
Re: branch index scan of multibranch pipeline job fails with hudson.plugins.git.GitException

The problem code path in AbstractGitSCMSource is only reachable with command line git versions older than git 2.8.0. That includes CentOS 6, CentOS 7, Debian 7, Debian 8, Ubuntu 14, and Ubuntu 16 in their default configurations.

CentOS 8, Ubuntu 18, Debian 9, and Debian 10 all include newer versions of command line git which avoid that code path and use the symref feature of newer command line git versions.
Reply all
Reply to author
Forward
0 new messages