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

Command "git rev-parse /develop^{commit}" returned status code 128

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Component/s: git-plugin
    • Labels:
    • Environment:
      Linux Ubuntu 3.2.0-58-generic x86_64
      Jenkins ver. 1.546
      Git Plugin 2.0 (also with 2.0.1 not working)
      Git server plugin 1.3
      Jenkins GIT client plugin 1.6.2
    • Similar Issues:

      Description

      I wanted to use the "automatic merging" functionality as described here: "Using Git, Jenkins and pre-build branch merging" ( https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin#GitPlugin-AdvancedFeatures ). I configured my job a described with the integration branch (Branch to merge to) configured to "developAutoMerge" and leaved the 'branch' field in the Git SCM blank.

      When I "Build now" I get following exception:

      Fetching changes from the remote Git repository
      Fetching upstream changes from git@REPOSITORY.git
      Seen branch in repository origin/develop
      Seen branch in repository origin/developAutoMerge
      Seen branch in repository origin/feature/blabla
      [...]
      Seen branch in repository origin/master
      Seen branch in repository origin/release/2.6.1
      Seen branch in repository origin/release/2.6.2
      Seen 13 remote branches
      Multiple candidate revisions
      Scheduling another build to catch up with blaServerBuild_developAutoMerge
      Merging Revision 6474f8ef91822e58edc55aad707d2725ff5a8431 (origin/feature/blabla) onto /developAutoMerge using resolve strategy
      FATAL: Command "git rev-parse /developAutoMerge^

      {commit}" returned status code 128:
      stdout: /developAutoMerge^{commit}

      stderr: fatal: ambiguous argument '/developAutoMerge^

      {commit}': unknown revision or path not in the working tree.
      Use '--' to separate paths from revisions

      hudson.plugins.git.GitException: Command "git rev-parse /developAutoMerge^{commit}

      " returned status code 128:
      stdout: /developAutoMerge^

      {commit}

      stderr: fatal: ambiguous argument '/developAutoMerge^{commit}

      ': unknown revision or path not in the working tree.
      Use '--' to separate paths from revisions

      at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1148)
      at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1125)
      at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1121)
      at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:937)
      at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:947)
      at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.revParse(CliGitAPIImpl.java:401)
      at hudson.plugins.git.GitAPI.revParse(GitAPI.java:257)
      at hudson.plugins.git.extensions.impl.PreBuildMerge.decorateRevisionToBuild(PreBuildMerge.java:62)
      at hudson.plugins.git.GitSCM.determineRevisionToBuild(GitSCM.java:795)
      at hudson.plugins.git.GitSCM.checkout(GitSCM.java:862)
      at hudson.model.AbstractProject.checkout(AbstractProject.java:1415)
      at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:652)
      at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
      at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:561)
      at hudson.model.Run.execute(Run.java:1678)
      at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
      at hudson.model.ResourceController.execute(ResourceController.java:88)
      at hudson.model.Executor.run(Executor.java:231)

      I found a similar problem by googling: https://groups.google.com/forum/#!topic/jenkinsci-dev/ek4hYR-z08k
      The proposed solution there was downgrading the Jenkins Git plugin from 2.0 to 1.4.0.

        Attachments

          Issue Links

            Activity

            Hide
            markewaite Mark Waite added a comment -

            That refspec is correct if the only branch you're using is the develop branch. The original description of this bug report says that the user was attempting to merge from another branch into the develop branch. Your refspec does not provide that other branch, so the source of the merge would not be available if your refspec were the only one used.

            You can place multiple refspecs (separated by spaces) into the refspec field, so you can list the two branches in your refspec.

            Show
            markewaite Mark Waite added a comment - That refspec is correct if the only branch you're using is the develop branch. The original description of this bug report says that the user was attempting to merge from another branch into the develop branch. Your refspec does not provide that other branch, so the source of the merge would not be available if your refspec were the only one used. You can place multiple refspecs (separated by spaces) into the refspec field, so you can list the two branches in your refspec.
            Hide
            rlagoue rlagoue added a comment - - edited

            Hello Mark

            thank you for your fast reaction. The other branch has been configure in the "additional behaviours"-part. Here is it

            The combination of both (the one in my previous comment and this one) used to work until 2.5.1

            Do you mean I should specify the "refspec" for the other branch too, if I want the "automatic merging" work in version released after 2.5.1?

            Thank you

            Show
            rlagoue rlagoue added a comment - - edited Hello Mark thank you for your fast reaction. The other branch has been configure in the "additional behaviours"-part. Here is it The combination of both (the one in my previous comment and this one) used to work until 2.5.1 Do you mean I should specify the "refspec" for the other branch too, if I want the "automatic merging" work in version released after 2.5.1? Thank you
            Hide
            markewaite Mark Waite added a comment -

            Yes. The refspec you listed in your repository definition says "copy the contents of the develop branch from the remote repository to the local repository", but then your merge definition says "merge to the master branch in the local repository". Since git plugin 2.5.1 (and 2.5.2) honor the refspec on initial clone, they don't copy the contents of the master branch from the remote repository to the local repository as part of the initial clone.

            The prototype 2.5.3 plugin (and 2.5.3 when it releases) will return to the earlier default behavior of ignoring the refspec on initial clone. I don't like that very much, but I can't see a way to satisfy the use cases which depend on the original behavior. without retaining the original "ignore the refspec on initial clone" as the default behavior.

            Show
            markewaite Mark Waite added a comment - Yes. The refspec you listed in your repository definition says "copy the contents of the develop branch from the remote repository to the local repository", but then your merge definition says "merge to the master branch in the local repository". Since git plugin 2.5.1 (and 2.5.2) honor the refspec on initial clone, they don't copy the contents of the master branch from the remote repository to the local repository as part of the initial clone. The prototype 2.5.3 plugin (and 2.5.3 when it releases) will return to the earlier default behavior of ignoring the refspec on initial clone. I don't like that very much, but I can't see a way to satisfy the use cases which depend on the original behavior. without retaining the original "ignore the refspec on initial clone" as the default behavior.
            Hide
            rlagoue rlagoue added a comment -

            OK. I understand a little better now. So I will wait for the next release, therefore it will not be necessary for me to adapt all my jenkins projects.

            Thank you for your time.

            Cheers

            Show
            rlagoue rlagoue added a comment - OK. I understand a little better now. So I will wait for the next release, therefore it will not be necessary for me to adapt all my jenkins projects. Thank you for your time. Cheers
            Hide
            markewaite Mark Waite added a comment -

            Fixed issue as described by rlagoue in git plugin 2.5.3, released 30 July 2016

            Show
            markewaite Mark Waite added a comment - Fixed issue as described by rlagoue in git plugin 2.5.3, released 30 July 2016

              People

              • Assignee:
                Unassigned
                Reporter:
                olibolib m r
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: