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

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.

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

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.

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

@Tomasz did You managed to configure jenkins this way?

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.

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.

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

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.

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.

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

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

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."

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

Fixed in git plugin 2.2.7, available from update center.

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

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

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 ?

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

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 - 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.