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?

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

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.

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

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.

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).

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^

# 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]

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

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..)

inebrious 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