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

Merge build fails when ref contains remote's name

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Blocker
    • Resolution: Done
    • Component/s: git-plugin
    • Labels:
      None
    • Environment:
      Jenkins 1.584
      git-plugin 2.3.5
    • Similar Issues:

      Description

      I experience the same problem as in JENKINS-21845 but the suggested workaround is not applicable (because my branch ref is very specific "origin/master").

      The failed command looks like "git rev-parse /origin/master". Adding the remote name "origin" in the merge build configuration only ends up to running the command like "git rev-parse origin/origin/master".

      It seems the code is joining the Remote and the Ref(Branch) with a "/", but that is incorrect when the ref is "origin/master" (this is recommended when trunk is ambiguous) — the command will become "git rev-parse /origin/master^

      {commit}

      ".

        Attachments

          Issue Links

            Activity

            Hide
            markewaite Mark Waite added a comment - - edited

            Can you provide step-by-step instructions to show the problem you are seeing, and what you're expecting to see instead?

            I don't understand based on your description if you're describing the value of branch to build (if so, have you reviewed the help on the branch to build field where it provides many different examples of ways to specify the branch or branches to be built) or if you're describing the branch to merge, or something entirely different.

            I can make guesses based on the phrases you've used, but we'll spend a lot of time guessing and working back and forth when it would be much better if you provide a series of numbered steps which show the problem when those steps are taken.

            It would also help if there are closed issues which you believe are specifically not related that you reference them by name, as in JENKINS-28911 (if that were one of the bugs which you specifically believe is not related to this bug)

            I would also help when describing changed behavior if you can identify the plugin version where the change occurred, or the last plugin version where the behavior matched what you wanted.

            Show
            markewaite Mark Waite added a comment - - edited Can you provide step-by-step instructions to show the problem you are seeing, and what you're expecting to see instead? I don't understand based on your description if you're describing the value of branch to build (if so, have you reviewed the help on the branch to build field where it provides many different examples of ways to specify the branch or branches to be built) or if you're describing the branch to merge, or something entirely different. I can make guesses based on the phrases you've used, but we'll spend a lot of time guessing and working back and forth when it would be much better if you provide a series of numbered steps which show the problem when those steps are taken. It would also help if there are closed issues which you believe are specifically not related that you reference them by name, as in JENKINS-28911 (if that were one of the bugs which you specifically believe is not related to this bug) I would also help when describing changed behavior if you can identify the plugin version where the change occurred, or the last plugin version where the behavior matched what you wanted.
            Hide
            andreineculau Andrei Neculau added a comment - - edited

            The first comment in JENKINS-21845 describes exactly the problem (and a workaround which is not applicable for this issue)

            Show
            andreineculau Andrei Neculau added a comment - - edited The first comment in JENKINS-21845 describes exactly the problem (and a workaround which is not applicable for this issue)
            Hide
            andreineculau Andrei Neculau added a comment -

            Mark, I have updated the ticket accordingly (I hope). Thank you

            Show
            andreineculau Andrei Neculau added a comment - Mark, I have updated the ticket accordingly (I hope). Thank you
            Hide
            markewaite Mark Waite added a comment - - edited

            You say that the first comment in JENKINS-21845 describes the problem exactly, but that the work around is not applicable. The first comment says:

            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.

            Please explain why that work around is not applicable. For example, why can't you declare your destination branch as "master" and the repository name as "origin"?

            Show
            markewaite Mark Waite added a comment - - edited You say that the first comment in JENKINS-21845 describes the problem exactly, but that the work around is not applicable. The first comment says: 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. Please explain why that work around is not applicable. For example, why can't you declare your destination branch as "master" and the repository name as "origin"?
            Hide
            andreineculau Andrei Neculau added a comment -

            I cannot declare my destination branch as such, since it comes down as a generator parameter. The sender uses origin/master (a value accepted by the git plugin in the "SCM" block) and cannot be changed.

            Several other branch formats (accepted by the git plugin in the "SCM" block) would fail as well: refs/heads/master, remotes/origin/master, refs/remotes/origin/master.

            Show
            andreineculau Andrei Neculau added a comment - I cannot declare my destination branch as such, since it comes down as a generator parameter. The sender uses origin/master (a value accepted by the git plugin in the "SCM" block) and cannot be changed. Several other branch formats (accepted by the git plugin in the "SCM" block) would fail as well: refs/heads/master, remotes/origin/master, refs/remotes/origin/master.
            Hide
            markewaite Mark Waite added a comment - - edited

            Andrei Neculau I don't understand your latest comment clearly enough to use it to duplicate the problem you're seeing. Can you provide a set of step by step instructions that will show the problem you're describing?

            You said:

            The sender uses origin/master (a value accepted by the git plugin in the "SCM" block) and cannot be changed

            Does that mean upstream job definition is passing a parameter to a downstream job, and you can't separate the parameters into separate values for repository name and branch name? Or, is there some other meaning in what you said?

            Which location accepts "origin/master" in the SCM block that cannot be changed? The branch name (where it could be changed to "master", as far as I know), or the refspec, or something else?

            Show
            markewaite Mark Waite added a comment - - edited Andrei Neculau I don't understand your latest comment clearly enough to use it to duplicate the problem you're seeing. Can you provide a set of step by step instructions that will show the problem you're describing? You said: The sender uses origin/master (a value accepted by the git plugin in the "SCM" block) and cannot be changed Does that mean upstream job definition is passing a parameter to a downstream job, and you can't separate the parameters into separate values for repository name and branch name? Or, is there some other meaning in what you said? Which location accepts "origin/master" in the SCM block that cannot be changed? The branch name (where it could be changed to "master", as far as I know), or the refspec, or something else?
            Hide
            markewaite Mark Waite added a comment -

            I can't duplicate this issue as reported.

            Show
            markewaite Mark Waite added a comment - I can't duplicate this issue as reported.

              People

              Assignee:
              Unassigned Unassigned
              Reporter:
              andreineculau Andrei Neculau
              Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: