• Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • git-plugin
    • None
    • Jenkins LTS on Debian Wheezy

      Git client plugin 1.10.2
      Git plugin 2.2.6

      We are using special merge simulator projects for feature branches where
      the idea is that the feature branch is automatically merged onto the
      master before compiling and testing it so that also the merging behavior
      is verified. All of these projects are multi configuration jobs. So far
      this worked quite well but since a few days we are noticing a weird
      behavior:

      In one of the feature branches we did some force pushing and after that
      we noticed two error conditions.

      1. The coordinator performed the merge successfully, which created a new
      revision with hash 5af79d528388216aa25a24c27f0a16d8dc55bdb6. All slaves
      of the multi configuration project then try to checkout that revision,
      which obviously does not exist in their local repositories. Hence, they
      end up with

      FATAL: Could not checkout master with start point
      5af79d528388216aa25a24c27f0a16d8dc55bdb6
      hudson.plugins.git.GitException: Could not checkout master with start
      point 5af79d528388216aa25a24c27f0a16d8dc55bdb6
      	at
      org.jenkinsci.plugins.gitclient.CliGitAPIImpl$8.execute(CliGitAPIImpl.java:1448)
      	at
      org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
      	at
      org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
      	at hudson.remoting.UserRequest.perform(UserRequest.java:118)
      	at hudson.remoting.UserRequest.perform(UserRequest.java:48)
      	at hudson.remoting.Request$2.run(Request.java:328)
      	at
      hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
      	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
      	at java.util.concurrent.FutureTask.run(FutureTask.java:166)
      	at
      java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
      	at
      java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
      	at java.lang.Thread.run(Thread.java:701)
      Caused by: hudson.plugins.git.GitException: Command "git checkout -f
      5af79d528388216aa25a24c27f0a16d8dc55bdb6" returned status code 128:
      stdout:
      stderr: fatal: reference is not a tree:
      5af79d528388216aa25a24c27f0a16d8dc55bdb6
      
      	at
      org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1276)
      	at
      org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1253)
      	at
      org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1249)
      	at
      org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1065)
      	at
      org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1075)
      	at
      org.jenkinsci.plugins.gitclient.CliGitAPIImpl$8.execute(CliGitAPIImpl.java:1431)
      	... 11 more
      

      2. After wiping the workspace of that job we ended up in a second error
      condition already on the coordinator side:

      Merging Revision 5af79d528388216aa25a24c27f0a16d8dc55bdb6 () onto
      origin/master using default strategy
      FATAL: Could not checkout master with start point
      5af79d528388216aa25a24c27f0a16d8dc55bdb6
      hudson.plugins.git.GitException: Could not checkout master with start
      point 5af79d528388216aa25a24c27f0a16d8dc55bdb6
      	at
      org.jenkinsci.plugins.gitclient.CliGitAPIImpl$8.execute(CliGitAPIImpl.java:1448)
      	at
      org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
      	at
      org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
      	at hudson.remoting.UserRequest.perform(UserRequest.java:118)
      	at hudson.remoting.UserRequest.perform(UserRequest.java:48)
      	at hudson.remoting.Request$2.run(Request.java:328)
      	at
      hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
      	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
      	at java.util.concurrent.FutureTask.run(FutureTask.java:166)
      	at
      java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
      	at
      java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
      	at java.lang.Thread.run(Thread.java:701)
      Caused by: hudson.plugins.git.GitException: Command "git checkout -f
      5af79d528388216aa25a24c27f0a16d8dc55bdb6" returned status code 128:
      stdout:
      stderr: fatal: reference is not a tree:
      5af79d528388216aa25a24c27f0a16d8dc55bdb6
      
      	at
      org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1276)
      	at
      org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1253)
      	at
      org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1249)
      	at
      org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1065)
      	at
      org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1075)
      	at
      org.jenkinsci.plugins.gitclient.CliGitAPIImpl$8.execute(CliGitAPIImpl.java:1431)
      	... 11 more
      

      It seems that the master cached the last revision (which it generated
      locally, so it will never be available after pulling) and refused to
      forget about this revision.

          [JENKINS-24934] Can't use matrix job with pre-build merge

          Wannes Sels added a comment -

          This looks a lot like JENKINS-25191.
          The issue is triggered when a commit is 'lost': a merge commit without push, or a force push can lead to missing commits. Jenkins then wants to build the last known revision, which it can't find.
          If this is indeed the case, this should be fixed in 2.2.8 release.

          You can work around this:

          • push a new commit. This may be a dummy commit (git commit --allow-empty), just to give Jenkins something new to build. Or you can...
          • remove the build(s) for the missing commits. This might mean deleting all the builds in the job.

          Wannes Sels added a comment - This looks a lot like JENKINS-25191 . The issue is triggered when a commit is 'lost': a merge commit without push, or a force push can lead to missing commits. Jenkins then wants to build the last known revision, which it can't find. If this is indeed the case, this should be fixed in 2.2.8 release. You can work around this: push a new commit. This may be a dummy commit (git commit --allow-empty), just to give Jenkins something new to build. Or you can... remove the build(s) for the missing commits. This might mean deleting all the builds in the job.

          As explained this happens in matrix jobs where the coordinator job itself is actually doing the merging. So at least the merging is completely out of the developer's control and obviously the coordinator will not push the merge result to any server. Will this situation also be fixed with the 2.2.8 release?

          Johannes Wienke added a comment - As explained this happens in matrix jobs where the coordinator job itself is actually doing the merging. So at least the merging is completely out of the developer's control and obviously the coordinator will not push the merge result to any server. Will this situation also be fixed with the 2.2.8 release?

          Wannes Sels added a comment -

          No, it probably wont be. The second problem you described should be fixed in 2.2.8
          the first problem you described is something else. The matrix coordinator job can do a merge, but has no way of sharing that new commit to the matrix jobs.

          As a workaround I suggest you split this in 2 jobs:
          1 job to do the merge and push in a temporary branch, optionally in a separate repository. This job can then trigger the matrix job and pass the git revision.
          Configure the matrix job with the temporary branch, and it will pick up the merge.

          Wannes Sels added a comment - No, it probably wont be. The second problem you described should be fixed in 2.2.8 the first problem you described is something else. The matrix coordinator job can do a merge, but has no way of sharing that new commit to the matrix jobs. As a workaround I suggest you split this in 2 jobs: 1 job to do the merge and push in a temporary branch, optionally in a separate repository. This job can then trigger the matrix job and pass the git revision. Configure the matrix job with the temporary branch, and it will pick up the merge.

          Wannes Sels added a comment -

          Does anyone have a suggestion on how to make sure the other matrix jobs can receive the (merge) commit(s) created by the matrix coordinator job?
          Should the matrix coordinator temporarily host a git server?
          Should the matrix coordinator create a bundle containing only those new commits and distribute it to the other matrix jobs?

          Wannes Sels added a comment - Does anyone have a suggestion on how to make sure the other matrix jobs can receive the (merge) commit(s) created by the matrix coordinator job? Should the matrix coordinator temporarily host a git server? Should the matrix coordinator create a bundle containing only those new commits and distribute it to the other matrix jobs?

            Unassigned Unassigned
            languitar Johannes Wienke
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: