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

${GIT_BRANCH} macro expands full branch name + remotes instead of short name

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • git-plugin
    • None
    • Centos OS 6,
      git version 1.7.12.4,
      Jenkins ver. 1.588,
      GIT plugin 2.2.7

      Docs says that ${GIT_BRANCH} macro should expands to the full branch name, such as 'origin/master'. Otherwise(without fullName parameter), it only expands to the short name, such as 'master', but without fullName parameter it expands to 'remotes/origin/master' with fullName parameter it doesn't work at all.

          [JENKINS-25465] ${GIT_BRANCH} macro expands full branch name + remotes instead of short name

          Mark Waite added a comment - - edited

          I can't duplicate the exact problems you're describing. I need more clarification of the steps you're taking, and what you're observing.

          The token macro plugin notes that the git plugin is a token producer, and then lists several plugins which are token consumers.

          When I use ${GIT_BRANCH} with a token consumer plugin (the build name setter plugin), I can see the following behavior:

          Input branch ${GIT_BRANCH} ${GIT_BRANCH,fullName=false} ${GIT_BRANCH,fullName=true} ${GIT_BRANCH,all}
          master remotes/origin/master remotes/origin/master refs/remotes/origin/master ${GIT_BRANCH,all}

          When I use ${GIT_BRANCH} with a plugin which is not a token consumer plugin (the XShell plugin), I see the following:

          Input branch ${GIT_BRANCH} ${GIT_BRANCH,fullName=false} ${GIT_BRANCH,fullName=true} ${GIT_BRANCH,all}
          master origin/master ${GIT_BRANCH,fullName=false} ${GIT_BRANCH,fullName=true} ${GIT_BRANCH,all}

          I believe that is an expected result for all the parameterized values, since the XShell plugin does not support token macro parameter expansion.

          Can you explain in more detail which plugin you're using to consume the token macro?

          Mark Waite added a comment - - edited I can't duplicate the exact problems you're describing. I need more clarification of the steps you're taking, and what you're observing. The token macro plugin notes that the git plugin is a token producer, and then lists several plugins which are token consumers. When I use ${GIT_BRANCH} with a token consumer plugin (the build name setter plugin), I can see the following behavior: Input branch ${GIT_BRANCH} ${GIT_BRANCH,fullName=false} ${GIT_BRANCH,fullName=true} ${GIT_BRANCH,all} master remotes/origin/master remotes/origin/master refs/remotes/origin/master ${GIT_BRANCH,all} When I use ${GIT_BRANCH} with a plugin which is not a token consumer plugin (the XShell plugin), I see the following: Input branch ${GIT_BRANCH} ${GIT_BRANCH,fullName=false} ${GIT_BRANCH,fullName=true} ${GIT_BRANCH,all} master origin/master ${GIT_BRANCH,fullName=false} ${GIT_BRANCH,fullName=true} ${GIT_BRANCH,all} I believe that is an expected result for all the parameterized values, since the XShell plugin does not support token macro parameter expansion. Can you explain in more detail which plugin you're using to consume the token macro?

          Aaron Levy added a comment -

          I have this issue also, at least if I understand what @metyl is saying. For me, any branch that has a "/" in the branch name, such as "dev/br1" results in an eventual ${GIT_BRANCH} value of "remotes/origin/dev/br1" (the full value of which is "refs/remotes/origin/dev/br1". The problem code here is in DefaultBuildChooser.java, in the getCandidateRevisions method starting at line 44. The logic in this method causes branches with slashes in the name to be sent to the 'else' statement at line 85, which adds the "refs/remotes" text that messes up the later ${GIT_BRANCH} value.

          Aaron Levy added a comment - I have this issue also, at least if I understand what @metyl is saying. For me, any branch that has a "/" in the branch name, such as "dev/br1" results in an eventual ${GIT_BRANCH} value of "remotes/origin/dev/br1" (the full value of which is "refs/remotes/origin/dev/br1". The problem code here is in DefaultBuildChooser.java, in the getCandidateRevisions method starting at line 44. The logic in this method causes branches with slashes in the name to be sent to the 'else' statement at line 85, which adds the "refs/remotes" text that messes up the later ${GIT_BRANCH} value.

          Horst Krause added a comment - - edited

          Contrary to the comment from 24. Nov in the build name setter plugin ${GIT_BRANCH} will result in "master" and not in "origin/master" or "remotes/origin/master".

          Horst Krause added a comment - - edited Contrary to the comment from 24. Nov in the build name setter plugin ${GIT_BRANCH} will result in "master" and not in "origin/master" or "remotes/origin/master".

          Matt Evans added a comment - - edited

          I attached screen shot of current help content (version 1.5.1). I do not think this is clear and should be modified

          For instance I have a branch develop/test which I want to set as build name.

          However, by default if I use only

          ${GIT_REVISION}

          I get origin/develop/test set as branch name. According to help content if fullName is NOT set then it does NOT expand to full name and so I expect develop/test.

          To fix this I added

           ${GIT_BRANCH,fullName=false}

          . Help content should be updated to indicate default behavior includes origin and you must set fullName to false to strip origin.

          Matt Evans added a comment - - edited I attached screen shot of current help content (version 1.5.1). I do not think this is clear and should be modified For instance I have a branch develop/test which I want to set as build name. However, by default if I use only ${GIT_REVISION} I get origin /develop/test set as branch name. According to help content if fullName is NOT set then it does NOT expand to full name and so I expect develop/test . To fix this I added ${GIT_BRANCH,fullName=false} . Help content should be updated to indicate default behavior includes origin and you must set fullName to false to strip origin.

            Unassigned Unassigned
            metyl Maciej Matys
            Votes:
            8 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated: