soft2412

I got the same issue as yours when I change the password and delete all data at Credential Manager>Windows Credentials.

Solution:

1. Delete tenant.cache from AppData/Local/GitCredentialManager

2. Edit "git:https://" prefixed entries from Credentials Manager>Windows Credentials with new password

OR

Delete all credentials with "git:https://" prefixed entries from Credentials Manager>Windows Credentials and then clone git project by command line to login with window credential prompt.

3. Build Jenkins job again. Done!

The git client plugin documentation recommends that you disable the credential manager that git for Windows offers to install by default. The Windows credential manager is a great help for interactive users. It can be a great distraction for automation use cases like Jenkins.

Please don't use the bug tracker to request help. The user mailing list and the chat system are better places to request help with configuration problems.

I'm seeing this error too - I've disabled Windows Credential manager:

using credential ea2a4045-c112-445c-8b6c-57c20e5a8699
Cloning the remote Git repository
Cloning with configured refspecs honoured and without tags
Cloning repository https://myurl.git
 > git.exe init E:\wp\ler-multibranch-pipeline_develop # timeout=10
Fetching upstream changes from https://myurl.git
 > git.exe --version # timeout=10
using GIT_ASKPASS to set credentials Bitbucket login for jenkins
 > git.exe fetch --no-tags --progress -- https://myurl.git +refs/heads/*:refs/remotes/origin/*
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Command "git.exe fetch --no-tags --progress -- https://myurl.git +refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: remote: Counting objects: 1436, done.

pogorman the message you're reporting is not the same message as the message that is reported here. The text in your message:

stderr: remote: Counting objects: 1436, done.

indicates that command line git successfully authenticated to the remote git server, requested data, and received data. The reason for the failure is not clear in the log output you included, but it is sufficient to show that initial authentication and initial connection are not the issue you are seeing.

I suspect a configuration issue in your case, or an issue that your remote git server has chosen to close the connection after the authentication was successful and data was transferred.

The original message reported in this bug report was not able to authenticate to the remote server.

markewaite apologies - I just realised they are not the same - I think the stack trace was similar though, here is the end of the console message:

Resolving deltas:  97% (1034/1056)   
Resolving deltas:  98% (1036/1056)   
Resolving deltas:  99% (1054/1056)   
Resolving deltas: 100% (1056/1056)   
Resolving deltas: 100% (1056/1056), done.

	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2172)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1864)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$500(CliGitAPIImpl.java:78)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:545)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:758)
	at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1152)
	at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1192)
	at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:124)
	at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:93)
	at org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:80)
	at org.jenkinsci.plugins.workflow.steps.SynchronousNonBlockingStepExecution.lambda$start$0(SynchronousNonBlockingStepExecution.java:47)
	at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
	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 java.lang.Thread.run(Unknown Source)

Should I create a new issue?

pogorman Please don't create a new issue until you've explored the question on the Jenkins users mailing list or on the chat channel. The stack trace that you've provided is a strong indication that the problem is specific to your environment. Environment specific questions are best handled in the mailing list or in the chat channels where many more people are watching and many more people are helping.

A bug report only gets the attention of the plugin maintainer. A discussion on the mailing list or in one of the chat channels allows many people that are not maintainers to assist with the question.

For example, in your case, it could be as simple as your repository having grown so large that it needs a longer timeout to complete the clone. It could also be that the workspace has existed for a long enough time with enough incremental updates that it needs a garbage collection from git gc.

Thanks Mark - the work around for us is to use ssh instead of http. I'm not really sure whats happening, all of our builds are done from a clean workspace, requiring a full clone. I can clone on the machine using http when I login as the jenkins user. This issue just came up when I updated the latest jenkins and git-client late last week (2.190.1 &  2.8.6).  Either way using ssh has fixed the issue

You may want to check the http logs on the git server to see if there is some indication why it is killing the connection from the Jenkins client that is trying to populate the workspace.

Hi, i am getting the same issue and i could not solve it, please help:

1. I am running jenkins from windows Server2012R2 and trying to add a git project and when i type the repository URL, i see the same error as below:  
2. Failed to connect to repository:Error performing git command: Is -remote -h  – https:myrepo      stdout:   stderr: fatal: Cannot prompt because user interactively has been disabled. fatal:Authentication failed for https:myrepo

amanga please don't use Jenkins issues to request help with a configuration problem. Very few people read Jenkins issue reports for the git plugin. Many, many more people are available to assist in the Jenkins user mailing list and in the Jenkins chat channels.

When we share the load with many people, more work is accomplished.