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

Loading library fails - Error fetching remote repo 'origin'

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      Loading shared library via Jenkinsfile. It works for a while, but then the error "ERROR: Error fetching remote repo 'origin'" is generated. The only way to remove the fault is to clear the workspace for the job. 

       

      Jenkinsfile:

      library identifier: 'myshared@master', retriever: modernSCM([$class: 'GitSCMSource',
      remote: 'https://xxxxxxxx/pipeline-shared/jenkins-pipeline-shared',
      credentialsId: 'MY_CREDENTIALS',
      branch: 'master',
      excludes: '',
      includes: '*',
      rawRefSpecs: 'refs/heads/master'
      ]) _

       

      Error log:

      Loading library myshared@master
      Attempting to resolve master from remote references...
       > git --version # timeout=10
      using GIT_ASKPASS to set credentials CREDENTIALS  > git ls-remote https://xxxxxxxx/pipeline-shared/jenkins-pipeline-shared# timeout=10
      Found match: refs/heads/master revision 9b1346587485736e0d09c107464b73efdd3088ac
       > git rev-parse --is-inside-work-tree # timeout=10
      Fetching changes from the remote Git repository
       > git config remote.origin.url https://xxxxxxxx/pipeline-shared/jenkins-pipeline-shared # timeout=10
      Fetching without tags
      Fetching upstream changes from https://xxxxxxxx/pipeline-shared/jenkins-pipeline-shared
       > git --version # timeout=10
      using GIT_ASKPASS to set credentials CREDENTIALS
       > git fetch --no-tags --progress https://xxxxxxxx/pipeline-shared/jenkins-pipeline-shared +refs/heads/:refs/remotes/origin/
      ERROR: Error fetching remote repo 'origin'
      hudson.plugins.git.GitException: Failed to fetch from https://xxxxxxxx/pipeline-shared/jenkins-pipeline-shared
      at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:888)
      at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1155)
      at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1186)
      at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:120)
      at org.jenkinsci.plugins.workflow.libs.SCMSourceRetriever.doRetrieve(SCMSourceRetriever.java:116)
      at org.jenkinsci.plugins.workflow.libs.SCMSourceRetriever.retrieve(SCMSourceRetriever.java:86)
      at org.jenkinsci.plugins.workflow.libs.LibraryAdder.retrieve(LibraryAdder.java:157)
      at org.jenkinsci.plugins.workflow.libs.LibraryStep$Execution.run(LibraryStep.java:207)
      at org.jenkinsci.plugins.workflow.libs.LibraryStep$Execution.run(LibraryStep.java:156)
      at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1$1.call(AbstractSynchronousNonBlockingStepExecution.java:47)
      at hudson.security.ACL.impersonate(ACL.java:290)
      at org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1.run(AbstractSynchronousNonBlockingStepExecution.java:44)
      at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
      at java.util.concurrent.FutureTask.run(FutureTask.java:266)
      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
      at java.lang.Thread.run(Thread.java:748)
      Caused by: hudson.plugins.git.GitException: Command "git fetch --no-tags --progress https://xxxxxxxx/pipeline-shared/jenkins-pipeline-shared +refs/heads/:refs/remotes/origin/" returned status code 255:
      stdout: 
      stderr: error: cannot open .git/FETCH_HEAD: Invalid argument

      at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2016)
      at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1735)
      at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:72)
      at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:420)
      at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:886)
      ... 16 more
      ERROR: Error fetching remote repo 'origin'

       

       

        Attachments

          Activity

          Hide
          zazzletian Tian Wang added a comment -

          you are right my bad.

          Show
          zazzletian Tian Wang added a comment - you are right my bad.
          Hide
          markewaite Mark Waite added a comment -

          Since m f has not responded in a month, I'm closing this as "cannot reproduce". If steps can be provided which duplicate the problem, we can reopen the report.

          Show
          markewaite Mark Waite added a comment - Since m f has not responded in a month, I'm closing this as "cannot reproduce". If steps can be provided which duplicate the problem, we can reopen the report.
          Hide
          ilatypov Ilguiz Latypov added a comment -

          I recognize the community spirit of the project and lack of hobby time for its maintainers, but closing an issue just because its submitters did not respond seems evil. The git plugin seems an utmost importance component of Jenkins. Closing issues or suggesting that reporters re-submit part of them as separate bugs always throws me off as if maintainers are not really to own the code.

          Show
          ilatypov Ilguiz Latypov added a comment - I recognize the community spirit of the project and lack of hobby time for its maintainers, but closing an issue just because its submitters did not respond seems evil. The git plugin seems an utmost importance component of Jenkins. Closing issues or suggesting that reporters re-submit part of them as separate bugs always throws me off as if maintainers are not really to own the code.
          Hide
          markewaite Mark Waite added a comment - - edited

          Ilguiz Latypov , thanks for your comments. You said:

          I recognize the community spirit of the project and lack of hobby time for its maintainers, but closing an issue just because its submitters did not respond seems evil.

          I don't want to be evil. I don't want to do things that are evil. However, I don't understand what you envision should happen as an alternative to what happened with this ticket. With this ticket:

          1. m f reported a problem and provided a stack trace which showed the problem
          2. I investigated the problem, was unable to reproduce the problem, and provided several ideas of conditions that might cause that type of problem
          3. I asked some further clarifying questions but received no responses to those clarifying questions or to my original investigation
          4. Tian Wang reported a different problem which included a different error message inside a stack trace
          5. I asked Tian Wang to submit a different bug report so that independent issues have distinct bug reports,
          6. Tian Wang agreed that it was a separate bug report
          7. A month after receiving no answers from m f on the original questions, I closed the bug because I could not reproduce it

          The Jenkins project Jira has "Cannot reproduce" as an allowed resolution of an issue. It is used by core and many different plugins. It allows those who attempt to verify a bug to explain to the submitter that they were unable to duplicate the bug. Resolving an issue as "Cannot reproduce" does not hide the issue. It does not prevent the issue from being reopened. It does not prevent someone from reopening it and assigning it to themselves to resolve.

          If I don't close an issue I cannot reproduce, then as a maintainer I must regularly filter the issues that I cannot reproduce by some other means. If I don't close an issue that I cannot reproduce, then I need to use another way of communicating to others that I could not reproduce the bug.

          Can you explain further what you think should have happened in this case and how those different steps would have been better?

          Show
          markewaite Mark Waite added a comment - - edited Ilguiz Latypov , thanks for your comments. You said: I recognize the community spirit of the project and lack of hobby time for its maintainers, but closing an issue just because its submitters did not respond seems evil. I don't want to be evil. I don't want to do things that are evil. However, I don't understand what you envision should happen as an alternative to what happened with this ticket. With this ticket: m f reported a problem and provided a stack trace which showed the problem I investigated the problem, was unable to reproduce the problem, and provided several ideas of conditions that might cause that type of problem I asked some further clarifying questions but received no responses to those clarifying questions or to my original investigation Tian Wang reported a different problem which included a different error message inside a stack trace I asked Tian Wang to submit a different bug report so that independent issues have distinct bug reports, Tian Wang agreed that it was a separate bug report A month after receiving no answers from m f on the original questions, I closed the bug because I could not reproduce it The Jenkins project Jira has "Cannot reproduce" as an allowed resolution of an issue. It is used by core and many different plugins. It allows those who attempt to verify a bug to explain to the submitter that they were unable to duplicate the bug. Resolving an issue as "Cannot reproduce" does not hide the issue. It does not prevent the issue from being reopened. It does not prevent someone from reopening it and assigning it to themselves to resolve. If I don't close an issue I cannot reproduce, then as a maintainer I must regularly filter the issues that I cannot reproduce by some other means. If I don't close an issue that I cannot reproduce, then I need to use another way of communicating to others that I could not reproduce the bug. Can you explain further what you think should have happened in this case and how those different steps would have been better?
          Hide
          ilatypov Ilguiz Latypov added a comment - - edited

          Ah sorry I targeted a wrong bug. I thought it was related to my frustration with the git plugin showing an error implying connectivity issues,

          fatal: Could not read from remote repository
          

          I think if the git plugin could add this trace message before invoking git,

          echo "Checking out branch ${branch} with credentials ${credentialsId} from ${url} ..."
          

          dozens of devops would be happier.

          My problem resolved when I saw that I was using a wrong credential, which did not agree with the error message.  Oh and whoever suggested to try a bare git@git../repo.git URL on StackOverflow: this ignored the port number after the host name (we use a TCP port 2222 for reasons unknown). The "proper" ssh://git@HOST:PORT/REPO.git URL worked.

          Show
          ilatypov Ilguiz Latypov added a comment - - edited Ah sorry I targeted a wrong bug. I thought it was related to my frustration with the git plugin showing an error implying connectivity issues, fatal: Could not read from remote repository I think if the git plugin could add this trace message before invoking git, echo "Checking out branch ${branch} with credentials ${credentialsId} from ${url} ..." dozens of devops would be happier. My problem resolved when I saw that I was using a wrong credential, which did not agree with the error message.  Oh and whoever suggested to try a bare  git@git../repo.git URL on StackOverflow: this ignored the port number after the host name (we use a TCP port 2222 for reasons unknown). The "proper" ssh://git@HOST:PORT/REPO.git URL worked.

            People

            • Assignee:
              Unassigned
              Reporter:
              emchi m f
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: