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

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

    XMLWordPrintable

    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 -

            I think you may have a different issue than is described in that posting on the mailing list. The "ambiguous argument" may be due to the absence of a remote name in the call to "git rev-parse". The failing seems to be "git rev-parse /developAutoMerge^

            {commit}", but I think it should be something like "git rev-parse origin/developAutoMerge^{commit}

            ".

            In the "Advanced" section of the git repository portion of the job definition, you'll find a field labeled "Name". That field needs a value for the merge use case you're attempting. I set mine to "upstream" and "downstream" to remind myself which one should be the destination of the push.

            Show
            markewaite Mark Waite added a comment - I think you may have a different issue than is described in that posting on the mailing list. The "ambiguous argument" may be due to the absence of a remote name in the call to "git rev-parse". The failing seems to be "git rev-parse /developAutoMerge^ {commit}", but I think it should be something like "git rev-parse origin /developAutoMerge^{commit} ". In the "Advanced" section of the git repository portion of the job definition, you'll find a field labeled "Name". That field needs a value for the merge use case you're attempting. I set mine to "upstream" and "downstream" to remind myself which one should be the destination of the push.
            Hide
            olibolib m r added a comment -

            Thanks! Your hints have helped me solve the problem!

            One more question for understanding only: Your naming ("upstream" and "downstream") makes sense only when I have more then one Git repository. Am I right?

            Show
            olibolib m r added a comment - Thanks! Your hints have helped me solve the problem! One more question for understanding only: Your naming ("upstream" and "downstream") makes sense only when I have more then one Git repository. Am I right?
            Hide
            markewaite Mark Waite added a comment -

            Yes, you're right. Unless you're using multiple repositories in a single job, it is probably best to name the repository "origin" so that it will have the typical name provided by git as a default.

            Show
            markewaite Mark Waite added a comment - Yes, you're right. Unless you're using multiple repositories in a single job, it is probably best to name the repository "origin" so that it will have the typical name provided by git as a default.
            Hide
            markewaite Mark Waite added a comment -

            It would be better if we could find a way to provide a much better error message than a failure from git rev-parse when the origin field is left empty, but I'm not sure if that failure message would be enough either.

            Show
            markewaite Mark Waite added a comment - It would be better if we could find a way to provide a much better error message than a failure from git rev-parse when the origin field is left empty, but I'm not sure if that failure message would be enough either.
            Hide
            rlagoue rlagoue added a comment -

            Hello
            I started facing this issue after an upgrade from 2.5.0 to 2.5.1. Downgrading to 2.5.0 solved the issue. The problem is still present in 2.5.2 I just tested it.

            Show
            rlagoue rlagoue added a comment - Hello I started facing this issue after an upgrade from 2.5.0 to 2.5.1. Downgrading to 2.5.0 solved the issue. The problem is still present in 2.5.2 I just tested it.
            Hide
            markewaite Mark Waite added a comment - - edited

            rlagoue a key change from 2.5.0 to 2.5.1 is that the original clone now honors the refspec (see JENKINS-31393) specified behind the "Advanced" button of the git plugin "Repositories" section. Could you check the refspec listed in that section of your job definition to confirm that it includes the develop branch?

            An alternate way to check if that is the problem affecting you is to test drive the pre-release build from pull request 425. That pull request switches back to the 2.5.0 (and before) default of always pulling all references with the initial clone, even if the refspec will then cause later operations to ignore those references.

            I believe that 2.5.1 refspec clone behavior is academically more correct than the 2.5.0 behavior, but JENKINS-36507 found at least one case where the academically more correct behavior can't be handled by a valid use of the git plugin (from the Gerrit plugin). So, git plugin 2.5.3 and later will require that users who want the academically more correct behavior must choose that behavior ("Honor refspec on initial clone") from the "Advanced clone behaviours" choice in the "Additional Behaviours".

            Show
            markewaite Mark Waite added a comment - - edited rlagoue a key change from 2.5.0 to 2.5.1 is that the original clone now honors the refspec (see JENKINS-31393 ) specified behind the "Advanced" button of the git plugin "Repositories" section. Could you check the refspec listed in that section of your job definition to confirm that it includes the develop branch? An alternate way to check if that is the problem affecting you is to test drive the pre-release build from pull request 425 . That pull request switches back to the 2.5.0 (and before) default of always pulling all references with the initial clone, even if the refspec will then cause later operations to ignore those references. I believe that 2.5.1 refspec clone behavior is academically more correct than the 2.5.0 behavior, but JENKINS-36507 found at least one case where the academically more correct behavior can't be handled by a valid use of the git plugin (from the Gerrit plugin). So, git plugin 2.5.3 and later will require that users who want the academically more correct behavior must choose that behavior ("Honor refspec on initial clone") from the "Advanced clone behaviours" choice in the "Additional Behaviours".
            Hide
            rlagoue rlagoue added a comment -

            Hello Mark..
            Here is the refspec value by now:

            Is there a problem there?

            Show
            rlagoue rlagoue added a comment - Hello Mark.. Here is the refspec value by now: Is there a problem there?
            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 Unassigned
              Reporter:
              olibolib m r
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: