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

Git Plugin 2.0 has changed contents of GIT_BRANCH

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • git-plugin
    • Jenkins 1.537; Git Plugin 2.0; Git Client Plugin 1.4.6; SCM API Plugin 0.2

      I've configured a job to clone a repository and use the "develop" branch. With the 1.5 plugin, GIT_PLUGIN was set to "develop". After upgrading to 2.0, GIT_BRANCH is now set to "origin/develop", which breaks my scripts which were relying on the previous value.

          [JENKINS-20446] Git Plugin 2.0 has changed contents of GIT_BRANCH

          Chris Post added a comment -

          +1 Here as well! This change completely broke all of my build scripts the first time around.

          I have since updated everything to accept both possibilities, but changes like this can cause pretty subtle but high-impact problems.

          Chris Post added a comment - +1 Here as well! This change completely broke all of my build scripts the first time around. I have since updated everything to accept both possibilities, but changes like this can cause pretty subtle but high-impact problems.

          Mark Waite added a comment -

          Removed git-client and git-parameter since the definition of the GIT_BRANCH environment variable is in git-plugin

          Mark Waite added a comment - Removed git-client and git-parameter since the definition of the GIT_BRANCH environment variable is in git-plugin

          Mark Waite added a comment -

          The git plugin wiki page documents the current behavior by saying that GIT_BRANCH is the 'name of the remote repository (defaults to origin), followed by name of the branch currently being used, e.g. "origin/master" or "origin/foo"'.

          There are now assertions in GitSCMTest which test that the description in the wiki page is correct, by testing that the GIT_BRANCH environment variable is "origin/master".

          With those two conditions, I'm reasonably confident that the git plugin 2.0 behavior is the expected current behavior and the intended future behavior.

          Mark Waite added a comment - The git plugin wiki page documents the current behavior by saying that GIT_BRANCH is the 'name of the remote repository (defaults to origin), followed by name of the branch currently being used, e.g. "origin/master" or "origin/foo"'. There are now assertions in GitSCMTest which test that the description in the wiki page is correct, by testing that the GIT_BRANCH environment variable is "origin/master". With those two conditions, I'm reasonably confident that the git plugin 2.0 behavior is the expected current behavior and the intended future behavior.

          Tim Pizey added a comment -

          I would like to see this issue reopened and the original change reverted.
          It is not possible to use the current variable with the sonar plugin:

          sonar.branch=$GIT_BRANCH

          breaks as the branch must be a branch, not an append of GIT_REMOTE and GIT_BRANCH.

          The documentation even says that this variable, called GIT_BRANCH, contains the remote and the branch separated by a slash.

          If you need the remote add a new variable called GIT_REMOTE please.

          There are many situations where string manipulation is not available and so expecting me to split on slash is not reasonable and not possible.

          Tim Pizey added a comment - I would like to see this issue reopened and the original change reverted. It is not possible to use the current variable with the sonar plugin: sonar.branch=$GIT_BRANCH breaks as the branch must be a branch, not an append of GIT_REMOTE and GIT_BRANCH. The documentation even says that this variable, called GIT_BRANCH, contains the remote and the branch separated by a slash. If you need the remote add a new variable called GIT_REMOTE please. There are many situations where string manipulation is not available and so expecting me to split on slash is not reasonable and not possible.

          Kevin Burge added a comment -

          While I was able to work around this issue (using CMake and Regular Expressions), as an end user, I can see Tim Pizey's point and agree. Another possibility is to add a variable in addition to GIT_REMOTE that has today's GIT_BRANCH value, like GIT_REF, or GIT_UPSTREAM_BRANCH or something like that. So, if anyone is depending on the current logic, they can simply rename the the variable they are referencing.

          Kevin Burge added a comment - While I was able to work around this issue (using CMake and Regular Expressions), as an end user, I can see Tim Pizey's point and agree. Another possibility is to add a variable in addition to GIT_REMOTE that has today's GIT_BRANCH value, like GIT_REF, or GIT_UPSTREAM_BRANCH or something like that. So, if anyone is depending on the current logic, they can simply rename the the variable they are referencing.

          Tim Pizey added a comment -

          SonarQube 5.0 does/will support slashes in branch names: https://jira.codehaus.org/browse/SONAR-3718

          I still do not want all my branches to be prefixed with 'origin/'.

          Tim Pizey added a comment - SonarQube 5.0 does/will support slashes in branch names: https://jira.codehaus.org/browse/SONAR-3718 I still do not want all my branches to be prefixed with 'origin/'.

          Horst Krause added a comment -

          The same for me. Updating to Sonar 5 just because of the slashes is quite an overkill.
          For example the Build Name Setter Plugin already gets GIT_BRANCH as input and just displays the shortened branch name. I would like the same for the sonar plugin.

          Horst Krause added a comment - The same for me. Updating to Sonar 5 just because of the slashes is quite an overkill. For example the Build Name Setter Plugin already gets GIT_BRANCH as input and just displays the shortened branch name. I would like the same for the sonar plugin.

          Mark Waite added a comment -

          I don't intend to change the 2.0 behavior of the GIT_BRANCH variable as returned by the plugin. It includes the remote and the branch name as described by the entry on the wiki page. Unit tests were added a year ago to assure that behavior would be retained across versions of the plugin.

          If someone wants to submit a pull request for an additional variable which contains the branch name without the remote, I'm willing to evaluate that. The pull request should include unit tests which confirm the behavior of the new variable. If such a pull request is submitted, it must not change the behavior of the existing GIT_BRANCH variable.

          Mark Waite added a comment - I don't intend to change the 2.0 behavior of the GIT_BRANCH variable as returned by the plugin. It includes the remote and the branch name as described by the entry on the wiki page. Unit tests were added a year ago to assure that behavior would be retained across versions of the plugin. If someone wants to submit a pull request for an additional variable which contains the branch name without the remote, I'm willing to evaluate that. The pull request should include unit tests which confirm the behavior of the new variable. If such a pull request is submitted, it must not change the behavior of the existing GIT_BRANCH variable.

          Horst Krause added a comment -

          I linked some issue also struggeling with GIT<->Sonar integration. Seems to be a quite common problem and would be very nice to get a solution. Especially as it seems to be quite simple for you.

          I would have provided the pull request, but the tests don't pass even before doing any change. Do I need any special setup on windows?

          Horst Krause added a comment - I linked some issue also struggeling with GIT<->Sonar integration. Seems to be a quite common problem and would be very nice to get a solution. Especially as it seems to be quite simple for you. I would have provided the pull request, but the tests don't pass even before doing any change. Do I need any special setup on windows?

          Horst Krause added a comment -

          I submitted pull request #304.
          https://github.com/jenkinsci/git-plugin/pull/304

          Horst Krause added a comment - I submitted pull request #304. https://github.com/jenkinsci/git-plugin/pull/304

            Unassigned Unassigned
            davidschmitt David Schmitt
            Votes:
            5 Vote for this issue
            Watchers:
            10 Start watching this issue

              Created:
              Updated: