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

Git plugin needs a better error diagnosis when failing to check out

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • git-plugin
    • None

      An user reported the following error in the IRC, where he fails to fetch from origin. As you can see, the Git plugin is not reporting the output from Git (nor the exit code), which makes trobule-shooting unnecessarily hard.

      In case of a failure, it should report the output and exit code.

      Checkout:workspace / /Users/administrator/Documents/Jenkins/jobs/FLOW3 raise submodules in Base distribution/workspace - hudson.remoting.LocalChannel@35b5a4ca
      Using strategy: Default
      Last Built Revision: Revision e94111b7f46946051dda9ff1ca30e2c0299e025c (origin/master)
      Checkout:workspace / /Users/administrator/Documents/Jenkins/jobs/FLOW3 raise submodules in Base distribution/workspace - hudson.remoting.LocalChannel@35b5a4ca
      Fetching changes from the remote Git repository
      Fetching upstream changes from ssh://review.typo3.org/FLOW3/Distributions/Base
      ERROR: Problem fetching from origin / origin - could be unavailable. Continuing anyway
      ERROR: Could not fetch from any repository
      FATAL: Could not fetch from any repository
      hudson.plugins.git.GitException: Could not fetch from any repository
      	at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:852)
      	at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:812)
      	at hudson.FilePath.act(FilePath.java:757)
      	at hudson.FilePath.act(FilePath.java:739)
      	at hudson.plugins.git.GitSCM.checkout(GitSCM.java:812)
      	at hudson.model.AbstractProject.checkout(AbstractProject.java:1182)
      	at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:521)
      	at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:416)
      	at hudson.model.Run.run(Run.java:1362)
      	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
      	at hudson.model.ResourceController.execute(ResourceController.java:88)
      	at hudson.model.Executor.run(Executor.java:145)
      

          [JENKINS-9052] Git plugin needs a better error diagnosis when failing to check out

          Matt Behrens added a comment -

          I would like this second this, for the increased error output and if this a "fetch" bug or related.

          I'm running Hudson ver. 1.380 and Git Plugin 1.1.6 and getting this same "ERROR: Could not fetch from any repository" when trying to fetch from a Github private repository. Logging in, switching to the hudson user and doing a `git fetch` from the repository succeeds, which makes me rule out an SSH/key issue.

          Matt Behrens added a comment - I would like this second this, for the increased error output and if this a "fetch" bug or related. I'm running Hudson ver. 1.380 and Git Plugin 1.1.6 and getting this same "ERROR: Could not fetch from any repository" when trying to fetch from a Github private repository. Logging in, switching to the hudson user and doing a `git fetch` from the repository succeeds, which makes me rule out an SSH/key issue.

          Andrew Bayer added a comment -

          Looks like this was actually fixed by commit a1f63b8d09323d3ce49a27ad3bd6fa7e745298e1 and will be in the next release.

          Andrew Bayer added a comment - Looks like this was actually fixed by commit a1f63b8d09323d3ce49a27ad3bd6fa7e745298e1 and will be in the next release.

          Mark Waite added a comment -

          The git plugin and git client plugin provide much more detailed output to show the operations being performed.

          The output is verbose enough that there is now a request to allow user control of the granularity of log output. Refer to JENKINS-24304 for the details of that feature request.

          Mark Waite added a comment - The git plugin and git client plugin provide much more detailed output to show the operations being performed. The output is verbose enough that there is now a request to allow user control of the granularity of log output. Refer to JENKINS-24304 for the details of that feature request.

          I believe this was resolved erroneously. The bug report was about the git plugin hiding error output, and the output Mark mentioned is only a log of all the commands issued – but if any of them fails, their stderr is still not logged. This sometimes makes debugging difficult, especially in the case of transient errors.

          It's not helpful at all, for example, if we have a single error 24h ago that fixed itself later, where all we get in the log is Error cloning remote repo 'origin' with no way to know if it was a timeout, authentication error or a broken workspace. Getting git's stderr into the log would be much better.

          I was about to report this as a new bug but found this instead. I can file it again if you prefer – but I think this one should be reopened.

          Tomasz Śniatowski added a comment - I believe this was resolved erroneously. The bug report was about the git plugin hiding error output , and the output Mark mentioned is only a log of all the commands issued – but if any of them fails, their stderr is still not logged. This sometimes makes debugging difficult, especially in the case of transient errors. It's not helpful at all, for example, if we have a single error 24h ago that fixed itself later, where all we get in the log is Error cloning remote repo 'origin' with no way to know if it was a timeout, authentication error or a broken workspace. Getting git's stderr into the log would be much better. I was about to report this as a new bug but found this instead. I can file it again if you prefer – but I think this one should be reopened.

          Mark Waite added a comment -

          tsniatowski thanks for looking for existing bugs before submitting a new bug. That is much appreciated!

          When this bug was closed, the diagnostic output was visible. Unfortunately, I made a change in late 2014 (Ocrober-ish) which removed that diagnostic output and made things much worse. Kohsuke recently submitted a fix for my mistake. If you'd be willing to test that fix before the next release of the git plugin, that would be a great help. That would let you confirm that the desired output is available in the specific case you're trying to diagnose.

          My apologies that I introduced a regression. That regression has now been documented through 2 or more bug reports (one from me, one from Jesse Glick).

          Mark Waite added a comment - tsniatowski thanks for looking for existing bugs before submitting a new bug. That is much appreciated! When this bug was closed, the diagnostic output was visible. Unfortunately, I made a change in late 2014 (Ocrober-ish) which removed that diagnostic output and made things much worse. Kohsuke recently submitted a fix for my mistake . If you'd be willing to test that fix before the next release of the git plugin, that would be a great help. That would let you confirm that the desired output is available in the specific case you're trying to diagnose. My apologies that I introduced a regression. That regression has now been documented through 2 or more bug reports (one from me, one from Jesse Glick).

          I'll try testing that some time this week, currently occupied elsewhere and couldn't find the time.

          Tomasz Śniatowski added a comment - I'll try testing that some time this week, currently occupied elsewhere and couldn't find the time.

          It is better now. I managed to do a quick test with a broken clone uri. Before:

          > git -c core.askpass=true fetch --tags --progress localhost.host:/home/BROKEN +refs/heads/*:refs/remotes/origin/*
          ERROR: Error fetching remote repo 'origin'
          ERROR: Error fetching remote repo 'origin'
          

          On master with the above change there's an ugly backtrace, but at the errror message is there:

          ERROR: Error fetching remote repo 'origin'
          hudson.plugins.git.GitException: Failed to fetch from localhost:/home/BROKEN
          	at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:737)
          	at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:984)
          	at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1015)
          	at hudson.scm.SCM.checkout(SCM.java:484)
          	at hudson.model.AbstractProject.checkout(AbstractProject.java:1270)
          	at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:609)
          	at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
          	at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:531)
          	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:374)
          Caused by: hudson.plugins.git.GitException: Command "git -c core.askpass=true fetch --tags --progress localhost:/home/BROKEN +refs/heads/*:refs/remotes/origin/*" returned status code 128:
          stdout: 
          stderr: fatal: '/home/BROKEN' does not appear to be a git repository
          fatal: Could not read from remote repository.
          
          Please make sure you have the correct access rights
          and the repository exists.
          
          	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1591)
          	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1379)
          	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:86)
          	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:324)
          	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:121)
          	at hudson.remoting.UserRequest.perform(UserRequest.java:49)
          	at hudson.remoting.Request$2.run(Request.java:325)
          	at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
          	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
          	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
          	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
          	at java.lang.Thread.run(Thread.java:745)
          	at ......remote call to test-2(Native Method)
          	at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1360)
          	at hudson.remoting.UserResponse.retrieve(UserRequest.java:221)
          	at hudson.remoting.Channel.call(Channel.java:753)
          	at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:145)
          	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
          	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.$Proxy48.execute(Unknown Source)
          	at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:735)
          	... 11 more
          ERROR: null
          

          That's a lot of rather not useful data – but I prefer this anyway. The second backtrace and ERROR:null is somewhat confusing though, and probably unnecessary.

          Tomasz Śniatowski added a comment - It is better now. I managed to do a quick test with a broken clone uri. Before: > git -c core.askpass=true fetch --tags --progress localhost.host:/home/BROKEN +refs/heads/*:refs/remotes/origin/* ERROR: Error fetching remote repo 'origin' ERROR: Error fetching remote repo 'origin' On master with the above change there's an ugly backtrace, but at the errror message is there: ERROR: Error fetching remote repo 'origin' hudson.plugins.git.GitException: Failed to fetch from localhost:/home/BROKEN at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:737) at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:984) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1015) at hudson.scm.SCM.checkout(SCM.java:484) at hudson.model.AbstractProject.checkout(AbstractProject.java:1270) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:609) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:531) 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:374) Caused by: hudson.plugins.git.GitException: Command "git -c core.askpass=true fetch --tags --progress localhost:/home/BROKEN +refs/heads/*:refs/remotes/origin/*" returned status code 128: stdout: stderr: fatal: '/home/BROKEN' does not appear to be a git repository fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1591) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1379) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:86) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:324) 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:121) at hudson.remoting.UserRequest.perform(UserRequest.java:49) at hudson.remoting.Request$2.run(Request.java:325) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) at ......remote call to test-2(Native Method) at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1360) at hudson.remoting.UserResponse.retrieve(UserRequest.java:221) at hudson.remoting.Channel.call(Channel.java:753) at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:145) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) 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.$Proxy48.execute(Unknown Source) at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:735) ... 11 more ERROR: null That's a lot of rather not useful data – but I prefer this anyway. The second backtrace and ERROR:null is somewhat confusing though, and probably unnecessary.

            abayer Andrew Bayer
            kohsuke Kohsuke Kawaguchi
            Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: