Hi Eric, thanks for the report.
Based on my understanding of freestyle jobs with a wildcard branch selector, the behaviour you have described is correct. When Jenkins receives a build trigger, it will poll Bitbucket for any new refs that have been pushed since the previous build, and it will queue jobs for all of those that match the branch selector. That would mean, in your previous example, that after pushing up those two branches, when the pull request is raised you trigger the polling process- the freestyle job will detect both new branches and queue builds for both of them. In the context of a freestyle job, this is what a pull request trigger is doing- triggering a scan whenever a pull request event occurs.
If you only want a build for `bugfix/a` to be created, you'd be better off setting up a multibranch pipeline, which will create a dedicated job for each individual branch- in that situation, you will only create a job for the ref that raised/updated the pull request, rather than for every branch in the repository, as each branch in a multibranch job only selects against it's own branch.
Re. your suggestion to perform dynamic branch filtering, I recommend following JENKINS-60340 which tracks env variable injection as a feature request.
I'll close this bug for now.
Bug
Major
Eric Evans
created issue -
Eric Evans
made changes -
Naj
made changes -
Hi Eric, thanks for the report.
Based on my understanding of freestyle jobs with a wildcard branch selector, the behaviour you have described is correct. When Jenkins receives a build trigger, it will poll Bitbucket for any new refs that have been pushed since the previous build, and it will queue jobs for all of those that match the branch selector. That would mean, in your previous example, that after pushing up those two branches, when the pull request is raised you trigger the polling process- the freestyle job will detect both new branches and queue builds for both of them. In the context of a freestyle job, this is what a pull request trigger is doing- triggering a scan whenever a pull request event occurs.
If you only want a build for `bugfix/a` to be created, you'd be better off setting up a multibranch pipeline, which will create a dedicated job for each individual branch- in that situation, you will only create a job for the ref that raised/updated the pull request, rather than for every branch in the repository, as each branch in a multibranch job only selects against it's own branch.
Re. your suggestion to perform dynamic branch filtering, I recommend following JENKINS-60340 which tracks env variable injection as a feature request.
I'll close this bug for now.