|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/d/optout.

Hi thanks.
Well, a couple of days has gone by with multiple jenkins using similar jobs (polling with parameterized branches). 6 jenkins masters each with 8 jobs. total of 12 branches. Seems to be working as desired with single branches resolved correctly and no unnecessary building due to changes to other branches.
I've not tried to recreate the initial problem. It was weird since it affected every jenkins master I had created, and then it started working right as I noted above, after messing with reinstall of jenkins and the git-plugin. (I think that was what led it to working..although there could have been some racy thing. I was doing combined polling plus scheduled build. I don't think there was any race effect going on, but if jenkins was looking at "last build" state somehow, you never know.
But looking at other open jiras in this area:
I found another open jira in this area that is interesting. I use a parameter ${BRANCH} to specify the branch. While there have been issues in the past with that, I notice in this jira a very odd behavior, where the behavior depends on the branch being different in the last build.
I was wondering if I copied jenkins setups with jobs pointing to master or a different branch, then modified the branch parameter in the job. (well yeah, I know that's how I setup all my different jenkins masters on different machines)
I'm wondering if the issue mentioned in this jira could have affected things..i.e. jenkins deciding that a branch variable wasn't what it was supposed to be.
BRANCH_TO_BUILD is equivalent to my use of BRANCH (${BRANCH}) in the jobs I was having problems with above.
quoting from this link
https://issues.jenkins-ci.org/browse/JENKINS-27349
Git SCM-polling uses wrong parameter values for a parametrized branchspec
to reproduce:
A parametrized build with parameter BRANCH_TO_BUILD, with default value "branch1"
Git SCM with branch specifier "${BRANCH_TO_BUILD}"
SCM polling enabled
Previous manual job launch with BRANCH_TO_BUILD=branch2
Expected:
When polling, BRANCH_TO_BUILD is set to branch1 (default value), so only updates to branch1 trigger a build.
Actual:
When polling, BRANCH_TO_BUILD is set to branch2 (value from last execution).
also:
https://issues.jenkins-ci.org/browse/JENKINS-27327
When specifying the branch to poll as part of a parameterized build, git-plugin uses last polled branch instead
another related one, but not what I was seeing:
https://issues.jenkins-ci.org/browse/JENKINS-27332
git-plugin no longer detects changes of branch with /
The basic question of using a parameterized branch seems to have been fixed in Mar...I had been wondering if that was affecting me (since I'm using a branch parameter) ..but this says it's fixed
https://issues.jenkins-ci.org/browse/JENKINS-27166
CLONE - Git SCM-polling doesn't work when using a parametrized branch-name