[JIRA] (JENKINS-38179) Authentication Error with GIT Client version 2.0.0

473 views
Skip to first unread message

Cole.mietzner@gmail.com (JIRA)

unread,
Sep 13, 2016, 5:37:01 PM9/13/16
to jenkinsc...@googlegroups.com
Cole Mietzner created an issue
 
Jenkins / Bug JENKINS-38179
Authentication Error with GIT Client version 2.0.0
Issue Type: Bug Bug
Assignee: Mark Waite
Components: git-client-plugin
Created: 2016/Sep/13 9:36 PM
Environment: Jenkins Master (2.7.4) is on Linux Server, Nodes are on Windows Server 2012 R2.
Priority: Critical Critical
Reporter: Cole Mietzner

I recently upgraded my Git Client plugin to 2.0.0 from 1.19.7. Immediately after jobs began failing due to an authentication issue. I rolled the plugin back to 1.19.7 and the jobs started passing. This is with TFS GIT.

Cloning the remote Git repository
Cloning repository https://REMOVED/_git/AppointmentsTribeTestAutomation
> C:\Program Files\Git\bin\git.exe init c:\Jenkins\workspace\Appointments_Test_ChromeNFW # timeout=10
Fetching upstream changes from https://REMOVED/_git/AppointmentsTribeTestAutomation
> C:\Program Files\Git\bin\git.exe --version # timeout=10
using GIT_ASKPASS to set credentials Credentials used for Version Control connections.
> C:\Program Files\Git\bin\git.exe fetch --tags --progress https:/REMOVED/_git/AppointmentsTribeTestAutomation +refs/heads/:refs/remotes/origin/
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Command "C:\Program Files\Git\bin\git.exe fetch --tags --progress https://REMOVED/_git/AppointmentsTribeTestAutomation +refs/heads/:refs/remotes/origin/" returned status code 128:
stdout:
stderr: fatal: Authentication failed for 'https://REMOVED/_git/AppointmentsTribeTestAutomation/'

at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1752)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1495)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:64)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:315)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:507)
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:120)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:332)
at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at hudson.remoting.Engine$1$1.run(Engine.java:85)
at java.lang.Thread.run(Unknown Source)
at ......remote call to REMOVED(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1416)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:253)
at hudson.remoting.Channel.call(Channel.java:781)
at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:145)
at sun.reflect.GeneratedMethodAccessor692.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.$Proxy75.execute(Unknown Source)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1042)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1082)
at hudson.scm.SCM.checkout(SCM.java:495)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1269)
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:1741)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:410)
ERROR: null

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,
Sep 13, 2016, 8:05:01 PM9/13/16
to jenkinsc...@googlegroups.com
Mark Waite commented on Bug JENKINS-38179
 
Re: Authentication Error with GIT Client version 2.0.0

What type of credential is being used for the job which is failing? I assume it is username / password (since it is https), but need you to confirm that is the case.

My authentication tests are running successfully using my account to visual studio online. Is there any publicly accessible location where you can see the same failure?

Are there any other things which are unique about your environment?

m.reeves@prospects.ac.uk (JIRA)

unread,
Sep 14, 2016, 6:29:03 AM9/14/16
to jenkinsc...@googlegroups.com

I've just opened JENKINS-38194 which seems similar (& in password)

Cole.mietzner@gmail.com (JIRA)

unread,
Sep 14, 2016, 10:22:04 AM9/14/16
to jenkinsc...@googlegroups.com

Mark Waite: The credentials are Username / Password using the credentials manager. I have not tried any other locations. I dont think there is anything unique about our environment. I was able to clone a repo on the node using the username and password without using Jenkins.

jeffrey.tresselt@ca.com (JIRA)

unread,
Sep 23, 2016, 1:59:01 PM9/23/16
to jenkinsc...@googlegroups.com

I have the same problem. Using the latest GIT Client Plugin version 2.0.0, authentication fails on my Windows slaves. Authentication does not fail on my Linux (ubuntu) slaves, only on my Windows slaves.

I had to revert back to the Git client plugin v1.21.0 to get things working again. This means I also had to revert the 'Git plugin' to version 2.6.0, so I cannot use the latest Git plugin v3.0.0 either.

Is there any status on this issue...? Is there any possible workaround...?

Thanks

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

unread,
Sep 23, 2016, 2:14:01 PM9/23/16
to jenkinsc...@googlegroups.com

One work around might be to switch from using the command line git implementation to use the JGit implementation. In "Global Tools Configuration" (Jenkins 2.x), you select "Git" and add "JGit" as an implementation. That then adds a "Git executable" pick list to your jobs which use git. From that pick list, choose "JGit". There are authentication cases which don't work with JGit, and there are some features which are not available in JGit (shallow clone, submodule support, and others), but for those cases where it works, it works reliably.

Another work around might be to assist with the evaluation of git client plugin pull request 216 which adds better authentication support to JGit by using a different library for http communication.

The ultimate work around is to revert to the earlier version of the git client plugin and the git plugin.

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

unread,
Sep 23, 2016, 2:15:02 PM9/23/16
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on Bug JENKINS-38179
One work around might be to switch from using the command line git implementation to use the JGit implementation.  In "Global Tools Configuration" (Jenkins 2.x), you select "Git" and add "JGit" as an implementation.  That then adds a "Git executable" pick list to your jobs which use git.  From that pick list, choose "JGit".  There are authentication cases which don't work with JGit, and there are some features which are not available in JGit (shallow clone, submodule support, and others), but for those cases where it works, it works reliably.

Another work around might be to assist with the evaluation of [git client plugin pull request 216|https://github.com/jenkinsci/git-client-plugin/pull/216] which adds better authentication support to JGit by using a different library for http communication.


The ultimate work around is to revert to the earlier version of the git client plugin and the git plugin.


Another alternative is to investigate the issue and propose a pull request to fix the issue.  I spent several hours last week at the Jenkins hackfest investigating and trying to understand the root of the issue, but was unable to find a final solution.  This week I've had to work for my employer, rather than working on my open source hobby (the Jenkins git plugin and git client plugin).

benjamin.d.goldman@gmail.com (JIRA)

unread,
Dec 13, 2016, 9:57:02 PM12/13/16
to jenkinsc...@googlegroups.com

we are having this same issue when running on RHEL flavor linux but not on Ubuntu.

its driving us all nuts as we are trying to prototype some stuff.

The scenario is as follows: One has no issue building out a SCM driven pipeline. One can even set up the SCM source (git) and see the authentication queues (no more red errors!) clear.

Everything looks awesome. Then when the job is run manually or triggered you get this:

Started by user admin


Cloning the remote Git repository

Cloning repository <gitrepo>
> git init /var/jenkins_home/workspace/<job-name>@script # timeout=10
Fetching upstream changes from <gitrepo>
> git --version # timeout=10


using GIT_ASKPASS to set credentials

> git fetch --tags --progress <gitrepo> +refs/heads/:refs/remotes/origin/
> git config remote.origin.url <gitrepo> # timeout=10
> git config --add remote.origin.fetch +refs/heads/:refs/remotes/origin/ # timeout=10
> git config remote.origin.url <gitrepo> # timeout=10
Fetching upstream changes from <gitrepo>


using GIT_ASKPASS to set credentials

> git fetch --tags --progress <gitrepo> +refs/heads/:refs/remotes/origin/
> git rev-parse refs/remotes/origin/master^

{commit} # timeout=10
> git rev-parse refs/remotes/origin/origin/master^{commit}

# timeout=10
Checking out Revision 42d3648ba16210a4cf2728788ab1614b6721a07b (refs/remotes/origin/master)
> git config core.sparsecheckout # timeout=10
> git checkout -f 42d3648ba16210a4cf2728788ab1614b6721a07b
First time build. Skipping changelog.
[Pipeline] node
Running on master in /var/jenkins_home/workspace/<job-name>
[Pipeline] {
[Pipeline] echo
start pipeline for ecp-view-classification app
[Pipeline] stage
[Pipeline]

{ (Preparation) [Pipeline] git Cloning the remote Git repository Cloning repository <gitrepo> > git init /var/jenkins_home/workspace/<job-name> # timeout=10 Fetching upstream changes from <gitrepo> > git --version # timeout=10 > git fetch --tags --progress <gitrepo> +refs/heads/*:refs/remotes/origin/* ERROR: Error cloning remote repo 'origin' hudson.plugins.git.GitException: Command "git fetch --tags --progress <gitrepo> +refs/heads/*:refs/remotes/origin/*" returned status code 128: stdout: stderr: fatal: Authentication failed for '<gitrepo>' 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$1.execute(CliGitAPIImpl.java:315) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:512) at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1054) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1094) at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:109) at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:83) at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:73) at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1$1.call(AbstractSynchronousNonBlockingStepExecution.java:47) at hudson.security.ACL.impersonate(ACL.java:221) 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:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) [Pipeline] }

[Pipeline] // stage
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
ERROR: null
Finished: FAILURE

benjamin.d.goldman@gmail.com (JIRA)

unread,
Dec 13, 2016, 10:19:03 PM12/13/16
to jenkinsc...@googlegroups.com

interestingly in /workspace i see a couple of directories:

1) <jobname>
2) <jobname>@script

in the second one i see that the Jenkinsfile and the whole repo seems to have been sync'd correctly...

there dont seem to be any disk space issues (ill double and triple check that next..)

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

unread,
Dec 14, 2016, 12:07:01 AM12/14/16
to jenkinsc...@googlegroups.com

Benjamin Goldman if your problem is the same as this bug, then it should be enough to install git client plugin 1.21.0 and git plugin 2.6.0. Since you removed the entire repository URL, I can't be sure that you're using https to access the repository. If you're not using https to access the repository, then the problem you're seeing is not this bug. This bug requires https protocol access to a repository with a username / password credential. Private key authentication and ssh or scp format URL's will not exercise this bug.

Unfortunately, I don't have any hints to offer you for diagnosing the issue. If you're using an ssh protocol, you might refer to https://help.github.com/articles/testing-your-ssh-connection/ or http://askubuntu.com/questions/336907/really-verbose-way-to-test-git-connection-over-ssh or https://confluence.atlassian.com/bitbucket/troubleshoot-ssh-issues-271943403.html

benjamin.d.goldman@gmail.com (JIRA)

unread,
Dec 14, 2016, 12:27:01 AM12/14/16
to jenkinsc...@googlegroups.com

Mark Waite Thanks for replying!

We are actually using the https URL. The UI shows the auth working, but when run a pipeline i get the "returned status code 128" error.

I attempted to pull the Jenkins file into the project and execute it directly and got the same issue. Very irritating.

I will attempt with a clean snap tomorrow and see about using the two recommended plugins above.

I am also going to make sure that we have git 1.8 + (I assume im way above that right now but ill check)

The part that is making everyone think we have lost it is that when we run one of the docker container builds (i forget which one) we dont have the problem. Very frustrating.

benjamin.d.goldman@gmail.com (JIRA)

unread,
Dec 14, 2016, 12:29:01 AM12/14/16
to jenkinsc...@googlegroups.com

The best part of this is if I drop into the jenkins user and go to the workspaces, i can git fetch - git will prompt me for uid then password, and everything works!

But as someone somewhere else said - if I wanted to do it that way I wouldnt be using Jenkins.

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

unread,
Dec 14, 2016, 12:31:01 AM12/14/16
to jenkinsc...@googlegroups.com

If your bare metal operating system is Red Hat 6 or a variant, then I believe your git version is prior to git 1.8. If it is Red Hat 7 or a variant, then your git version is prior to git 1.9.

Docker containers get the git version bundled with the container version. For example, the Jenkins container uses a Ubuntu operating system as its base, so has a git 2.1 version in it.

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

unread,
Dec 14, 2016, 12:36:01 AM12/14/16
to jenkinsc...@googlegroups.com

Are you including the credentials ID in your pipeline definition? If not, you might refer to https://github.com/MarkEWaite/jenkins-bugs/blob/JENKINS-34309/Jenkinsfile for an example Jenkinsfile which uses a credential definition in the clone step.

benjamin.d.goldman@gmail.com (JIRA)

unread,
Dec 14, 2016, 12:41:02 AM12/14/16
to jenkinsc...@googlegroups.com

yeah - 2 part problem:

1) cant get the Jenkinsfile from GIT (blah..)
2) when I run it manually in a pipline job it gives me the same connection error.

I really need to resolve both issues.. so ill cover all of the bases tomorrow.

probably also going to do a write up of this - as i cannot be the only person/group/etc hitting this wall and not knowing what to do.

and i just checked the Jenkinsfile and it has this:

// Get some code from a GitHub repository
git credentialsId: 'XXXsome hash thing generated from the syntax editorXXX', url: 'https://<ourrepo>.git'

So i suspect your recommendations will be spot on.

benjamin.d.goldman@gmail.com (JIRA)

unread,
Dec 14, 2016, 12:43:01 AM12/14/16
to jenkinsc...@googlegroups.com

And this is a problem:
cloud@ecp-jenkins-server-test:~> git version
git version 1.8.3.1

Ill report back if we were able to make this all work as a work around! thanks for the help.

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

unread,
Dec 14, 2016, 12:51:01 AM12/14/16
to jenkinsc...@googlegroups.com

Git 1.8.3 supports credentials and password authentication. I test it regularly in git plugin and git client plugin test automation.

Git 1.8.3 has some issues when attempting to perform a shallow clone.

Git 1.8.3 was released May 2013. It's a "mature" (old) release. Because it is used in RHEL 7 (and CentOS 7 and Oracle Linux 7 and ...) I continue to test with it. It works well enough (for me) with pipeline jobs, multi-configuration jobs, freestyle jobs, and more.

benjamin.d.goldman@gmail.com (JIRA)

unread,
Dec 14, 2016, 2:01:06 AM12/14/16
to jenkinsc...@googlegroups.com

so your recommendation solved half my problems.

i am now able to successfully run a pipeline script from inside a pipeline job. I am still getting almost exactly the same error when trying to do SCM based scripts though... and as you might imagine this is where the real value comes (this is the mic-drop of features....)

At least we can see it TRYING to work this time:

Started by user admin
Cloning the remote Git repository

Cloning repository https://<secretrepo>.git
> git init /var/lib/jenkins/workspace/secretproject@script # timeout=10
Fetching upstream changes from https://<secretrepo>.git
> git --version # timeout=10
using .gitcredentials to set credentials
> git config --local credential.username s.secretgroups.cm # timeout=10
> git config --local credential.helper store --file=/tmp/git3075561283563803618.credentials # timeout=10
> git -c core.askpass=true fetch --tags --progress https://<secretrepo>.git +refs/heads/:refs/remotes/origin/
> git config --local --remove-section credential # timeout=10
> git config remote.origin.url https://<secretrepo>.git # timeout=10


> git config --add remote.origin.fetch +refs/heads/:refs/remotes/origin/ # timeout=10

> git config remote.origin.url https://<secretrepo>.git # timeout=10
Fetching upstream changes from https://<secretrepo>.git
using .gitcredentials to set credentials
> git config --local credential.username s.platformgrp.cm # timeout=10
> git config --local credential.helper store --file=/tmp/git2484614980651109123.credentials # timeout=10
> git -c core.askpass=true fetch --tags --progress https://<secretrepo>.git +refs/heads/:refs/remotes/origin/
> git config --local --remove-section credential # timeout=10
> git rev-parse refs/remotes/origin/master^

{commit} # timeout=10
> git rev-parse refs/remotes/origin/origin/master^{commit}

# timeout=10
Checking out Revision 42d3648ba16210a4cf2728788ab1614b6721a07b (refs/remotes/origin/master)
> git config core.sparsecheckout # timeout=10
> git checkout -f 42d3648ba16210a4cf2728788ab1614b6721a07b
First time build. Skipping changelog.
[Pipeline] node

Running on master in /var/lib/jenkins/workspace/secretproject
[Pipeline] {
[Pipeline] echo
start pipeline for my_build app


[Pipeline] stage
[Pipeline] { (Preparation)
[Pipeline] git
Cloning the remote Git repository

Cloning repository https://<secretrepo>.git
> git init /var/lib/jenkins/workspace/secretproject # timeout=10
Fetching upstream changes from https://<secretrepo>.git
> git --version # timeout=10
> git -c core.askpass=true fetch --tags --progress https://<secretrepo>.git +refs/heads/:refs/remotes/origin/


ERROR: Error cloning remote repo 'origin'

hudson.plugins.git.GitException: Command "git -c core.askpass=true fetch --tags --progress https://<secretrepo>.git +refs/heads/:refs/remotes/origin/" returned status code 128:
stdout:
stderr: fatal: Authentication failed for 'https://<secretrepo>.git/'

benjamin.d.goldman@gmail.com (JIRA)

unread,
Dec 14, 2016, 11:02:01 PM12/14/16
to jenkinsc...@googlegroups.com

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

unread,
Dec 15, 2016, 1:27:02 PM12/15/16
to jenkinsc...@googlegroups.com

Benjamin Goldman can you describe further what work around worked?

benjamin.d.goldman@gmail.com (JIRA)

unread,
Dec 15, 2016, 4:05:33 PM12/15/16
to jenkinsc...@googlegroups.com

Yes - we dropped back to git client plugin 1.21.0 and git plugin 2.6.0.

I did nothing else and all of our problems went away.

Thanks a ton.

benjamin.d.goldman@gmail.com (JIRA)

unread,
Dec 15, 2016, 4:06:02 PM12/15/16
to jenkinsc...@googlegroups.com

the SECOND error i pasted above was NOT due to the same problem but due to the fact that I spun up yet another box did not consider how I was managing credentials.

benjamin.d.goldman@gmail.com (JIRA)

unread,
Dec 15, 2016, 4:12:03 PM12/15/16
to jenkinsc...@googlegroups.com

Mark Waite i will have some time late tonight or tomorrow to go back and VERIFY that the change you recommended fixed things and output the various versions of stuff involved (jenkins, os, git, plugins, git server etc)

Ill do this by reproducing the error in a new build, and verifying that the only thing done to fix it is the downgrade.

after i posted the previous comments it was pointed out to me that I should be super thorough here so you guys can benefit from our problem.. so ill do just that.

benjamin.d.goldman@gmail.com (JIRA)

unread,
Dec 16, 2016, 3:35:02 PM12/16/16
to jenkinsc...@googlegroups.com

Mark Waite it was a ID10-T error or PEBCAK.

Not an instance of the bug. I cannot reproduce 4 times in a row now rebuilding entirely on my own from scripts.

Sorry

scm_issue_link@java.net (JIRA)

unread,
Jan 14, 2017, 7:34:03 PM1/14/17
to jenkinsc...@googlegroups.com

Code changed in jenkins
User: Mark Waite
Path:
src/main/java/org/jenkinsci/plugins/gitclient/CliGitAPIImpl.java
src/test/java/org/jenkinsci/plugins/gitclient/CliGitAPIImplAuthTest.java
http://jenkins-ci.org/commit/git-client-plugin/f7b7cb995f5aaf22dcc49ccc48b980e5d1ce7ecc
Log:
Test JENKINS-40116, JENKINS-38194, JENKINS-38179 & JENKINS-38138

Confirm that characters which Windows requires be escaped in a batch
file can be used as characters in a git password (as used through https
with a username / password combination).

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

unread,
Jan 16, 2017, 10:18:02 AM1/16/17
to jenkinsc...@googlegroups.com

If you'd like to test a prototype build, for a short time it will be available from the ci.jenkins.io server. Upload it manually, restart your Jenkins server, and see if it helps in your case.

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

unread,
Jan 17, 2017, 6:47:02 AM1/17/17
to jenkinsc...@googlegroups.com
Mark Waite resolved as Fixed
 

Believed to be fixed in git client plugin 2.2.1 16 Jan 2016

Jenkins / Bug JENKINS-38179
Change By: Mark Waite
Status: Open Resolved
Resolution: Fixed

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

unread,
Nov 27, 2019, 6:19:03 PM11/27/19
to jenkinsc...@googlegroups.com
Mark Waite closed an issue as Fixed
Change By: Mark Waite
Status: Resolved Closed
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
Atlassian logo
Reply all
Reply to author
Forward
0 new messages