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

"stderr: fatal: reference is not a tree" error in jenkins

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Critical
    • Resolution: Not A Defect
    • Component/s: git-plugin
    • Labels:
      None
    • Similar Issues:

      Description

      While building project after raising PR on git, jobs fail intermittently with the following failures, though the frequency is low but it becomes annoying:

      17:42:27  > /usr/bin/git config --get remote.origin.url # timeout=10
      17:42:27 using GIT_ASKPASS to set credentials Git Personal Access Token
      17:42:27  > /usr/bin/git merge --ff 6d775a8a8fe4f2c2ed4b97d87eb608a524c2806f # timeout=10
      17:42:27  > /usr/bin/git config core.sparsecheckout # timeout=10
      17:42:27  > /usr/bin/git checkout -f 6d775a8a8fe4f2c2ed4b97d87eb608a524c2806f # timeout=10
      17:42:27 FATAL: Could not checkout 6d775a8a8fe4f2c2ed4b97d87eb608a524c2806f
      17:42:27 hudson.plugins.git.GitException: Command "/usr/bin/git checkout -f 6d775a8a8fe4f2c2ed4b97d87eb608a524c2806f" returned status code 128:
      17:42:27 stdout: 
      17:42:27 stderr: fatal: reference is not a tree: 6d775a8a8fe4f2c2ed4b97d87eb608a524c2806f
      17:42:27 
      17:42:27 	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:2450)
      17:42:27 	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$1100(CliGitAPIImpl.java:84)
      17:42:27 	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$9.execute(CliGitAPIImpl.java:2767)
      17:42:27 Also:   hudson.remoting.Channel$CallSiteStackTrace: Remote call to Evergreen-29
      17:42:27 		at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1741)
      17:42:27 		at hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:356)
      17:42:27 		at hudson.remoting.Channel.call(Channel.java:955)
      

      Any help would be really appreciated as this has been pending for long and nothing seems to be working.

        Attachments

          Activity

          Hide
          markewaite Mark Waite added a comment -

          This is not a defect. It is a job configuration error.

          Steps you can take to identify your job configuration error include:

          • Identify the branch or branches that contain the specific commit. If the specific commit is not in one of the branches, then correct the job definition to not reference that commit
          • Confirm that those branches are included in the refspec that is used to checkout that workspace. If the branch with that commit is not included in the refspec used to checkout the workspace, adjust the job definition to use the correct refspec
          Show
          markewaite Mark Waite added a comment - This is not a defect. It is a job configuration error. Steps you can take to identify your job configuration error include: Identify the branch or branches that contain the specific commit. If the specific commit is not in one of the branches, then correct the job definition to not reference that commit Confirm that those branches are included in the refspec that is used to checkout that workspace. If the branch with that commit is not included in the refspec used to checkout the workspace, adjust the job definition to use the correct refspec
          Hide
          praverma Prateek VERMA added a comment - - edited

          Hi Mark Waite Thanks for your valuable inputs on this issue.
          While i was going through the configuration, one thing i could not understand is that our PR triggers job on multiple(around 10) machines each running different test suites. And this issue comes for one or two test suites for same PR execution while runs fine for rest of the test suites.

          Show
          praverma Prateek VERMA added a comment - - edited Hi Mark Waite Thanks for your valuable inputs on this issue. While i was going through the configuration, one thing i could not understand is that our PR triggers job on multiple(around 10) machines each running different test suites. And this issue comes for one or two test suites for same PR execution while runs fine for rest of the test suites.
          Hide
          markewaite Mark Waite added a comment -

          If you are using static agents that are not discarded after each build, then the agents where the checkout is successful probably have an existing workspace that already used a refspec that included the branch with that commit. The failing agents probably needed to create new workspaces and the definition of the workspace does not include the commit.

          Show
          markewaite Mark Waite added a comment - If you are using static agents that are not discarded after each build, then the agents where the checkout is successful probably have an existing workspace that already used a refspec that included the branch with that commit. The failing agents probably needed to create new workspaces and the definition of the workspace does not include the commit.
          Hide
          praverma Prateek VERMA added a comment -

          Actually jobs are same for all those agents meaning that there is no way for agents to pick refspec from apart from the same jenkins job that we use to trigger separate subjobs on these. This main job does the sync part where it fails for some agents.

          Show
          praverma Prateek VERMA added a comment - Actually jobs are same for all those agents meaning that there is no way for agents to pick refspec from apart from the same jenkins job that we use to trigger separate subjobs on these. This main job does the sync part where it fails for some agents.
          Hide
          markewaite Mark Waite added a comment -

          The difference between one agent and the next is not usually in the job definition, it is in the content of the workspace on the agent. If the commit is found on one agent and not found on another, then the commit is available on one agent and not available on the other. The history of builds on the agent are the most likely cause why one agent is "lucky" and includes the commit and another agent is "unlucky" and does not include the commit.

          Check that your job definition showing the failure is operating on a branch or tag that contains the commit that is being referenced. If it does not, then the job definition needs to be corrected.

          Show
          markewaite Mark Waite added a comment - The difference between one agent and the next is not usually in the job definition, it is in the content of the workspace on the agent. If the commit is found on one agent and not found on another, then the commit is available on one agent and not available on the other. The history of builds on the agent are the most likely cause why one agent is "lucky" and includes the commit and another agent is "unlucky" and does not include the commit. Check that your job definition showing the failure is operating on a branch or tag that contains the commit that is being referenced. If it does not, then the job definition needs to be corrected.

            People

            Assignee:
            markewaite Mark Waite
            Reporter:
            praverma Prateek VERMA
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: