Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-59387

Failed to connect to repository : Command "C:\Program Files\Git\cmd\git.exe ls-remote -h — my Repository URL HEAD"

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      When I I copy my Private project link to Jenkins, I get some error like this:

      Failed to connect to repository : Command "C:\Program Files\Git\cmd\git.exe ls-remote -h -- https://github.sydney.edu.au/SOFT2412-2019S2/WBYWJD_WYWJD_Team15.git HEAD" returned status code 128:
stdout:
stderr: Logon failed, use ctrl+c to cancel basic credential prompt.
error: cannot spawn C:\WINDOWS\TEMP\pass6522988368209337473.bat: No error
fatal: could not read Username for 'https://github.sydney.edu.au': terminal prompts disabled

      And when I try to build something there, the log of Confirmation failure is like that.

      Started by GitHub push by zzho0631
Running as SYSTEM
Building in workspace C:\Program Files (x86)\Jenkins\workspace\Team15
using credential ec3b9de9-638a-472d-a137-668b7c1744f8
Cloning the remote Git repository
Cloning repository https://github.sydney.edu.au/SOFT2412-2019S2/WBYWJD_WYWJD_Team15.git
 > git.exe init C:\Program Files (x86)\Jenkins\workspace\Team15 # timeout=10
Fetching upstream changes from https://github.sydney.edu.au/SOFT2412-2019S2/WBYWJD_WYWJD_Team15.git
 > git.exe --version # timeout=10
using GIT_ASKPASS to set credentials 
 > git.exe fetch --tags --force --progress -- https://github.sydney.edu.au/SOFT2412-2019S2/WBYWJD_WYWJD_Team15.git +refs/heads/*:refs/remotes/origin/*
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Command "git.exe fetch --tags --force --progress -- https://github.sydney.edu.au/SOFT2412-2019S2/WBYWJD_WYWJD_Team15.git +refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: Logon failed, use ctrl+c to cancel basic credential prompt.
error: cannot spawn C:\WINDOWS\TEMP\pass2346010482442283795.bat: No error
fatal: could not read Username for 'https://github.sydney.edu.au': terminal prompts disabled

    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 hudson.scm.SCM.checkout(SCM.java:504)
    at hudson.model.AbstractProject.checkout(AbstractProject.java:1206)
    at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
    at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
    at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
    at hudson.model.Run.execute(Run.java:1815)
    at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
    at hudson.model.ResourceController.execute(ResourceController.java:97)
    at hudson.model.Executor.run(Executor.java:429)
ERROR: Error cloning remote repo 'origin'
Finished: FAILURE

        Attachments

          Activity

          Ascending order - Click to sort in descending order
          4 older comments
          Hide
          Permalink
          markewaite Mark Waite added a comment - - edited

          Philip O'Gorman 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.

          Show
          markewaite Mark Waite added a comment - - edited Philip O'Gorman 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.
          Hide
          Permalink
          pogorman Philip O'Gorman added a comment -

          Mark Waite 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?

           

          Show
          pogorman Philip O'Gorman added a comment - Mark Waite 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?  
          Hide
          Permalink
          markewaite Mark Waite added a comment -

          Philip O'Gorman 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.

          Show
          markewaite Mark Waite added a comment - Philip O'Gorman 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 .
          Hide
          Permalink
          pogorman Philip O'Gorman added a comment -

          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

          Show
          pogorman Philip O'Gorman added a comment - 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
          Hide
          Permalink
          markewaite Mark Waite added a comment -

          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.

          Show
          markewaite Mark Waite added a comment - 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.

            People

            Assignee:
            soft2412 An Yan
            Reporter:
            soft2412 An Yan
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: