Jenkins is building "most recent commit" and not necessarily the correct branch for a new PR

[derekatkins]

I and another developer have been working in parallel on three different dev branches in Bitbucket (cloud) in the same project (although it appears this issue can be done with one developer in two branches). The issue appears to be that when Jenkins gets notified, it is not necessarily checking out the correct git branch (or commit!) and, indeed, appears to be using the most recent commit and not the desired branch.

As an example, I am working in branches A and B and my co-worker is working in branch C, but we can ignore him because I was able to obtain this issue all on my own:

I push some changes to branch A. Then I push some changes to branch B. Then I make a PR for branch B. Then I make a PR for branch A.

Both of these will trigger a build, but it'll build the same commit (the last commit on branch B), and it wont build branch A (unless I push another commit into branch A).

I have Jenkins (2.319.2) configured with BBPPR (2.8.1). I have the project configured as: Source: GIT Branches: **

[X] Build with BitBucket Push and Pull Request Plugin Bitbucket Cloud Pull Request Created Bitbucket Cloud Pull Request Updated Push Bitbucket Cloud Push Allowed Branches: master

The BBPPR Hook Log for the project reports:

Last BitBucket Push

Started on Mar 8, 2022 11:53:49 AM
Polling SCM changes on built-in
Using strategy: Default
[poll] Last Built Revision: Revision 7390eea02b41edc8101dda7de55458214afcea31 (origin/BAS-129-normalize-ethernet-up-down-logs)
The recommended git tool is: NONE
using credential 1bc4d338-adf7-48e8-bedf-90ef3c15709f
 > git rev-parse --resolve-git-dir /var/lib/jenkins/workspace/BACnet-C/.git # timeout=10
Fetching changes from the remote Git repositories
 > git config remote.origin.url [email protected]:xxx.git # timeout=10
Fetching upstream changes from [email protected]:xxx.git
 > git --version # timeout=10
 > git --version # 'git version 2.27.0'
using GIT_SSH to set credentials 
 > git fetch --tags --force --progress -- [email protected]:xxx.git +refs/heads/*:refs/remotes/origin/* # timeout=10
Polling for changes in
Seen branch in repository origin/BAS-31
Seen branch in repository origin/BAS-31.1
Seen branch in repository origin/BAS-68
Seen branch in repository origin/BAS-69
Seen branch in repository origin/BAS-73
Seen branch in repository origin/BAS-78
Seen branch in repository origin/BAS-79
Seen branch in repository origin/BAS-8
Seen branch in repository origin/BAS-86
Seen branch in repository origin/BAS-89
Seen branch in repository origin/BAS-90
Seen branch in repository origin/BAS-93
Seen branch in repository origin/DOME-3
Seen branch in repository origin/DOME-4
Seen branch in repository origin/HEAD
Seen branch in repository origin/bas186_7
Seen branch in repository origin/bugfix/BAS-31
Seen branch in repository origin/bugfix/BAS-96
Seen 44 remote branches
 > git show-ref --tags -d # timeout=10
Done. Took 0.69 sec

Unfortunately I have BB Webhook events turned off, and I didn't have debugging turned on.. I can do that (in a test project) if you need logs. Please let me know what else you might need from me.

Honestly, I am very surprised to see this behavior. I THOUGHT it was working before, but I guess I always created the PR shortly after pushing to the PR'd branch and before any other commits got pushed into the repo. But it looks like the trigger just causes it to build the most recent commit in the repo, regardless of what branch that is on.