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

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

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.

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.

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.

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.

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.

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.

your workaround worked.

Thanks.

inebrious can you describe further what work around worked?

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.

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.

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

markewaite 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

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

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.

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