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

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

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      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)

        Attachments

          Issue Links

            Activity

            martoe Martin E created issue -
            Hide
            martoe Martin E added a comment -

            WOrkaround: disable branch filtering if the branch-specifier contains variables (see patchfile)

            Show
            martoe Martin E added a comment - WOrkaround: disable branch filtering if the branch-specifier contains variables (see patchfile)
            martoe Martin E made changes -
            Field Original Value New Value
            Attachment JENKINS-14276.patch [ 22068 ]
            martoe Martin E made changes -
            Description 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 checkous 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 (brcause the "${Branch}" value isn't resolved when polling)

            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)
            Hide
            tfnico tfnico added a comment -

            I'm experiencing a similar problem. I've described my use-case on the mailing list:

            https://groups.google.com/d/topic/jenkinsci-users/iqqUollgpKY/discussion

            My initial idea was to override the Git branch specifier with some environment variable, like GIT_OVERRIDE_BRANCH or something like that. Haven't look into the Git Plugin sources yet though.

            Show
            tfnico tfnico added a comment - I'm experiencing a similar problem. I've described my use-case on the mailing list: https://groups.google.com/d/topic/jenkinsci-users/iqqUollgpKY/discussion My initial idea was to override the Git branch specifier with some environment variable, like GIT_OVERRIDE_BRANCH or something like that. Haven't look into the Git Plugin sources yet though.
            Hide
            homes2001 Dominik Bieringer added a comment -

            I am facing the same problem; patch from Martin worked for me

            Show
            homes2001 Dominik Bieringer added a comment - I am facing the same problem; patch from Martin worked for me
            Hide
            ndeloof Nicolas De Loof added a comment -

            You can't expect polling to work if you have branch set by a build parameter (where to pick up a value ?). Use a GitRevisionBuildParameters to set the revision/branch to build when you wan't to trigger the job from another one.

            Show
            ndeloof Nicolas De Loof added a comment - You can't expect polling to work if you have branch set by a build parameter (where to pick up a value ?). Use a GitRevisionBuildParameters to set the revision/branch to build when you wan't to trigger the job from another one.
            ndeloof Nicolas De Loof made changes -
            Status Open [ 1 ] Resolved [ 5 ]
            Resolution Won't Fix [ 2 ]
            Hide
            kretes Tomasz Bartczak added a comment -

            Why cannot I expect it to work? If parameter has a default value - then there is a value to use when polling. Anyway current problem is https://issues.jenkins-ci.org/browse/JENKINS-20427

            Show
            kretes Tomasz Bartczak added a comment - Why cannot I expect it to work? If parameter has a default value - then there is a value to use when polling. Anyway current problem is https://issues.jenkins-ci.org/browse/JENKINS-20427
            Hide
            metyl Maciej Matys added a comment -

            @Tomasz did You managed to configure jenkins this way?

            Show
            metyl Maciej Matys added a comment - @Tomasz did You managed to configure jenkins this way?
            Hide
            aaronlab aaronlab added a comment -

            I agree ... this needs to work off the default value of the parameter. I've used older version of the Git plugin for years and it worked fine. I finally upgraded to Git plugin version 2.2.2 and its not working anymore. It seems trivial to resolve the polling to default value of the parameter. +1 for re-opening and fixing this issue.

            Show
            aaronlab aaronlab added a comment - I agree ... this needs to work off the default value of the parameter. I've used older version of the Git plugin for years and it worked fine. I finally upgraded to Git plugin version 2.2.2 and its not working anymore. It seems trivial to resolve the polling to default value of the parameter. +1 for re-opening and fixing this issue.
            Hide
            aaronlab aaronlab added a comment -

            I'm re-opening this because it used to work fine in older version of the Git plugin. I've been stuck on the old plugin for years because newer versions broke this functionality and it needs to work again. I finally upgraded to version 2.2.2 today for other reasons and of course this is still broken. Can you please take another look and make it resolve the parameter with their default values during polling?

            Thanks.

            Show
            aaronlab aaronlab added a comment - I'm re-opening this because it used to work fine in older version of the Git plugin. I've been stuck on the old plugin for years because newer versions broke this functionality and it needs to work again. I finally upgraded to version 2.2.2 today for other reasons and of course this is still broken. Can you please take another look and make it resolve the parameter with their default values during polling? Thanks.
            aaronlab aaronlab made changes -
            Resolution Won't Fix [ 2 ]
            Status Resolved [ 5 ] Reopened [ 4 ]
            Hide
            diranged Matt Wise added a comment -

            Agreed – we upgraded to 2.2.2 today and suddenly several of our builds started running constantly. Please fix this .

            Show
            diranged Matt Wise added a comment - Agreed – we upgraded to 2.2.2 today and suddenly several of our builds started running constantly. Please fix this .
            Hide
            aaronlab aaronlab added a comment -

            Yeah, for sure.. I got around this for now by setting an environment variable, which basically means that polling can only work off that one branch, which is fine for now. Please fix asap.

            Show
            aaronlab aaronlab added a comment - Yeah, for sure.. I got around this for now by setting an environment variable, which basically means that polling can only work off that one branch, which is fine for now. Please fix asap.
            Hide
            drdt Don Ross added a comment -

            We use a parameter because it is the only way to have other parts of the build job know what the branch is. IE, we set a parameter for the branch name, and use it when polling, and when pushing our results to Coverity, and when sending email notifications. Otherwise, every time I create a new job I need to manually edit all of these settings and you know I am going to miss one. Or three.

            Show
            drdt Don Ross added a comment - We use a parameter because it is the only way to have other parts of the build job know what the branch is. IE, we set a parameter for the branch name, and use it when polling, and when pushing our results to Coverity, and when sending email notifications. Otherwise, every time I create a new job I need to manually edit all of these settings and you know I am going to miss one. Or three.
            Hide
            daniviga Daniele Vigano added a comment -

            I can confirm this bug. With Jenkins 1.572, git client plugin 1.9.2 and git plugin 2.2.2 the polling module does not resolve our "$branch" variable, set in the parametrized build configuration:
            Started on Jul 17, 2014 10:50:00 AM
            Using strategy: Default
            [poll] Last Built Revision: Revision 2d1a169f855f69312b4b47819283063ea15c1448 (origin/master)
            > git ls-remote -h git://github.com/gem/oq-nrmllib.git $branch
            Done. Took 0.54 sec
            No changes

            Show
            daniviga Daniele Vigano added a comment - I can confirm this bug. With Jenkins 1.572, git client plugin 1.9.2 and git plugin 2.2.2 the polling module does not resolve our "$branch" variable, set in the parametrized build configuration: Started on Jul 17, 2014 10:50:00 AM Using strategy: Default [poll] Last Built Revision: Revision 2d1a169f855f69312b4b47819283063ea15c1448 (origin/master) > git ls-remote -h git://github.com/gem/oq-nrmllib.git $branch Done. Took 0.54 sec No changes
            Hide
            kenpoole Ken Poole added a comment -

            We are trying to switch to a configuration where we use a parameter with a default value for the branch to poll/update to - the update part works great - but the poll always says it is not up to date so we get continuous rebuilds as indicated above. We have git client 1.9.1, git plugin 2.2.2, Jenkins 1.571

            Show
            kenpoole Ken Poole added a comment - We are trying to switch to a configuration where we use a parameter with a default value for the branch to poll/update to - the update part works great - but the poll always says it is not up to date so we get continuous rebuilds as indicated above. We have git client 1.9.1, git plugin 2.2.2, Jenkins 1.571
            Hide
            tlehmann Thomas Lehmann added a comment -

            We have the same problem: Jenkins 1.572, Git Plugin 2.2.1 and Git Client Plugin 1.8.0
            When I remove the variables from the branch field writing the branch name directly there the polling stops.

            Additionally I would like to know how to solve the upgrade problem. We have a Centos 6 with Git installed
            by the package manager being the version 1.7.1. The plugin section says for upgrading the Git Plugin:

            "This plugin allows use of Git as a build SCM. A recent Git runtime is required (1.7.9 minimum, 1.8.x recommended). Plugin is only tested on official git client. Use exotic installations at your own risks."

            Show
            tlehmann Thomas Lehmann added a comment - We have the same problem: Jenkins 1.572, Git Plugin 2.2.1 and Git Client Plugin 1.8.0 When I remove the variables from the branch field writing the branch name directly there the polling stops. Additionally I would like to know how to solve the upgrade problem. We have a Centos 6 with Git installed by the package manager being the version 1.7.1. The plugin section says for upgrading the Git Plugin: "This plugin allows use of Git as a build SCM. A recent Git runtime is required (1.7.9 minimum, 1.8.x recommended). Plugin is only tested on official git client. Use exotic installations at your own risks."
            Hide
            scm_issue_link 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/ea62814db213b41b0e8fe99dbca6898aa369da97
            Log:
            [FIXED JENKINS-20427] [FIXED JENKINS-14276] expanded vars in branch spec for remote polling

            Show
            scm_issue_link 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/ea62814db213b41b0e8fe99dbca6898aa369da97 Log: [FIXED JENKINS-20427] [FIXED JENKINS-14276] expanded vars in branch spec for remote polling
            markewaite Mark Waite made changes -
            Status Reopened [ 4 ] Open [ 1 ]
            Hide
            markewaite Mark Waite added a comment -

            Fixed in git plugin 2.2.7, available from update center.

            Show
            markewaite Mark Waite added a comment - Fixed in git plugin 2.2.7, available from update center.
            markewaite Mark Waite made changes -
            Status Open [ 1 ] Resolved [ 5 ]
            Resolution Fixed [ 1 ]
            markewaite Mark Waite made changes -
            Status Resolved [ 5 ] Closed [ 6 ]
            Hide
            klundgren Kristofer Lundgren added a comment -

            Bug still exist in git plugin 2.3

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

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

            Show
            klundgren Kristofer Lundgren added a comment - I would really appreciate if you (Mark) applied this patch to git plugin 2.3 as well.
            klundgren Kristofer Lundgren made changes -
            Resolution Fixed [ 1 ]
            Status Closed [ 6 ] Reopened [ 4 ]
            Assignee Nicolas De Loof [ ndeloof ] Mark Waite [ markewaite ]
            Hide
            markewaite 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)

            Show
            markewaite 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)
            markewaite Mark Waite made changes -
            Status Reopened [ 4 ] Resolved [ 5 ]
            Resolution Fixed [ 1 ]
            Hide
            markewaite Mark Waite added a comment -

            Fix included in git plugin 2.3.1, released 29 Nov 2014

            Show
            markewaite Mark Waite added a comment - Fix included in git plugin 2.3.1, released 29 Nov 2014
            markewaite Mark Waite made changes -
            Status Resolved [ 5 ] Closed [ 6 ]
            Hide
            amorisseau 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 ?

            Show
            amorisseau 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 ?
            Hide
            scm_issue_link 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

            Show
            scm_issue_link 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
            Hide
            jblanchard 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

            Show
            jblanchard 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
            Hide
            pmv 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.

            Show
            pmv 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.
            Hide
            jblanchard 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.

            Show
            jblanchard 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 .
            Hide
            pmv 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.

            Show
            pmv 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.
            sirianni Eric Sirianni made changes -
            Link This issue is related to JENKINS-8335 [ JENKINS-8335 ]
            rtyler R. Tyler Croy made changes -
            Workflow JNJira [ 144908 ] JNJira + In-Review [ 205968 ]

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: