-
Bug
-
Resolution: Not A Defect
-
Major
-
Jenkins: 2.361.1
BitBucket Server Integration Plugin: 3.3.1
Git Plugin: 4.12.1
When using a Freestyle job with a wildcard branch filter, the source of PR's are ignored when multiple branches exist. So let's say you push changes to branch bugfix/a and then branch bugfix/b both of which were branched from QA. If you create a PR for bugfix/a, it's bugfix/b that is cloned and compiled and then a second job is queued for bugfix/a. If the PR is for bugfix/a then it would be expected that it's bugfix/a that is pulled.
Seems to me that the easiest fix would be to populate parameters or env variables with the branch, tag, and Id supplied in the PR payload for dynamic branch filtering.
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.