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

Git SCM-polling doesn't work when using a parametrized branch-name

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • git-plugin
    • None

      Setup:

      • Git Plugin 1.1.20
      • a parameterized build with parameter "Branch", default "**"
      • Git SCM with branch specifier "${Branch}"
      • SCM polling activated

      Intended behaviour:

      • if any branch changes, Jenkins checks out and builds this branch
      • when executed manually, the user enters the name of the branch to be built

      Actual behaviour:

      • no changes are detected (because the "${Branch}" value isn't resolved when polling)

          [JENKINS-14276] Git SCM-polling doesn't work when using a parametrized branch-name

          Bug still exist in git plugin 2.3

          Kristofer Lundgren added a comment - Bug still exist in git plugin 2.3

          I would really appreciate if you (Mark) applied this patch to git plugin 2.3 as well.

          Kristofer Lundgren added a comment - I would really appreciate if you (Mark) applied this patch to git plugin 2.3 as well.

          Mark Waite added a comment -

          The change has been cherry-picked into the branch for the next release of git plugin 2.3 (for example, 2.3.1)

          Mark Waite added a comment - The change has been cherry-picked into the branch for the next release of git plugin 2.3 (for example, 2.3.1)

          Mark Waite added a comment -

          Fix included in git plugin 2.3.1, released 29 Nov 2014

          Mark Waite added a comment - Fix included in git plugin 2.3.1, released 29 Nov 2014

          Wonderful ! It's still not working !
          Well... it almost work...
          The parameter variable is resolved. But it doesn't retrieve the proper default value.
          It retrieve the previous value if it was define by an user.

          user case :

          Let's say i have a choice parameter :

          branche v1
          branche v2
          master

          the parameter variable is git_branche_v
          the default value is **

          in the branch specifier is set at */${GIT_BRANCHE_V}

          If a dev do a git push in branche v1
          the scm polling use /*.

          then if a user manually call the build and select branche v1
          the scm polling use */branche v1.

          And then if a dev do a git push in branche v2
          the scm polling use */branche v1.

          It seems that the variable is not reset properly. or maybe the workspace is not reset.

          any workaround ?

          Antoine Morisseau added a comment - Wonderful ! It's still not working ! Well... it almost work... The parameter variable is resolved. But it doesn't retrieve the proper default value. It retrieve the previous value if it was define by an user. user case : Let's say i have a choice parameter : branche v1 branche v2 master the parameter variable is git_branche_v the default value is ** in the branch specifier is set at */${GIT_BRANCHE_V} If a dev do a git push in branche v1 the scm polling use / *. then if a user manually call the build and select branche v1 the scm polling use */branche v1. And then if a dev do a git push in branche v2 the scm polling use */branche v1. It seems that the variable is not reset properly. or maybe the workspace is not reset. any workaround ?

          Code changed in jenkins
          User: Nicolas De Loof
          Path:
          src/main/java/hudson/plugins/git/GitSCM.java
          http://jenkins-ci.org/commit/git-plugin/75e4e6c2282e069bd26fbce0ead19c1c5b722c04
          Log:
          [FIXED JENKINS-20427] [FIXED JENKINS-14276] expanded vars in branch spec for remote polling

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Nicolas De Loof Path: src/main/java/hudson/plugins/git/GitSCM.java http://jenkins-ci.org/commit/git-plugin/75e4e6c2282e069bd26fbce0ead19c1c5b722c04 Log: [FIXED JENKINS-20427] [FIXED JENKINS-14276] expanded vars in branch spec for remote polling

          I created a pull request [1] to address the issue mentioned by Antoine Morisseau (polling should take the default value of a param, not the one from the last build).
          It also fixes the commit notification for those parametrized jobs.

          [1] https://github.com/jenkinsci/git-plugin/pull/293

          Jean Blanchard added a comment - I created a pull request [1] to address the issue mentioned by Antoine Morisseau (polling should take the default value of a param, not the one from the last build). It also fixes the commit notification for those parametrized jobs. [1] https://github.com/jenkinsci/git-plugin/pull/293

          pmv added a comment -

          FYI for any others searching Jira - in my testing the issue Antoine identifies 3 comments above and Jean created the pull request for is no longer an issue in version 2.3.5 of the plugin.

          pmv added a comment - FYI for any others searching Jira - in my testing the issue Antoine identifies 3 comments above and Jean created the pull request for is no longer an issue in version 2.3.5 of the plugin.

          Actually it's not. Created JENKINS-27349 for it to have proper tracking.

          Also created related issues (that I also fixed in my original PR): JENKINS-27351 and JENKINS-27352.

          Jean Blanchard added a comment - Actually it's not. Created JENKINS-27349 for it to have proper tracking. Also created related issues (that I also fixed in my original PR): JENKINS-27351 and JENKINS-27352 .

          pmv added a comment -

          @Jean Blanchard - you are correct. 2.3.5 did change behavior and seemed to cover more of our use case than 2.3.4, but yes, it seems your patches are still needed. I've voted for your tickets. Also, for what it's worth, I have been running a SNAPSHOT version with your changes on our Jenkins instance with 1000s of jobs and haven't seen any issues. Thanks for the patches - looking forward to seeing them integrated into future releases.

          pmv added a comment - @Jean Blanchard - you are correct. 2.3.5 did change behavior and seemed to cover more of our use case than 2.3.4, but yes, it seems your patches are still needed. I've voted for your tickets. Also, for what it's worth, I have been running a SNAPSHOT version with your changes on our Jenkins instance with 1000s of jobs and haven't seen any issues. Thanks for the patches - looking forward to seeing them integrated into future releases.

            markewaite Mark Waite
            martoe Martin E
            Votes:
            12 Vote for this issue
            Watchers:
            22 Start watching this issue

              Created:
              Updated:
              Resolved: