[JENKINS-61008] Branch API 2.5.4 does not recognize manually triggered build commit and kicks off build after scan

We are seeding Bitbucket repositories in Jenkins using Bitbucket Team/Project type of jobs and you can find our job DSL file attached.

We ran into an issue where user triggered builds on master branches get rebuilt upon branch indexing (e.g. when someone triggers the multibranch pipeline scan). Note that in this scenario the Jenkins hook in Bitbucket repo was not configured correctly so the new commit did not automatically trigger a build when, for example, a pull request was merged to the master branch.

 

Steps to reproduce (this is without having a Jenkins hook properly configured in Bitbucket so we can mimic users triggering jobs):

• Kick off a master branch build so it's up-to-date and successful (building latest commit in master: f264be47)


• Create a pull request from testbranch to master with new changes


• Scan multibranch pipeline -> Jenkins detects the pull request and kicks off a build


• Merge pull request -> nothing happens due to no hook


• Manually kick off a master branch build (building pull request merge commit in master: 835d8b37)


• Scan multibranch pipeline

Expected result:

No changes detected: master (still at 835d8b37)

Actual result:

Changes detected: master (f264be47 → 835d8b37)

Scheduled build for branch: master

 

The same steps produced the following result when testbranch-1 was merged into testbranch-2 (essentially between two non-named branches):

Changes detected: testbranch-2 (null → 39fb6587)

No automatic build triggered for testbranch-2

---
Originally reported by cansuerdogan, imported from: Branch API 2.5.4 does not recognize manually triggered build commit and kicks off build after scan

• status: Open
  
• priority: Minor
  
• component(s): branch-api-plugin
  
• resolution: Unresolved
  
• votes: 0
  
• watchers: 2
  
• imported: 20251211-141027
  

Raw content of original issue

We are seeding Bitbucket repositories in Jenkins using Bitbucket Team/Project type of jobs and you can find our job DSL file attached.


We ran into an issue where user triggered builds on master branches get rebuilt upon branch indexing (e.g. when someone triggers the multibranch pipeline scan). Note that in this scenario the Jenkins hook in Bitbucket repo was not configured correctly so the new commit did not automatically trigger a build when, for example, a pull request was merged to the master branch.


 


Steps to reproduce (this is without having a Jenkins hook properly configured in Bitbucket so we can mimic users triggering jobs):



	
Kick off a master branch build so it's up-to-date and successful (building latest commit in master: f264be47)

	
Create a pull request from testbranch to master with new changes

	
Scan multibranch pipeline -> Jenkins detects the pull request and kicks off a build

	
Merge pull request -> nothing happens due to no hook

	
Manually kick off a master branch build (building pull request merge commit in master: 835d8b37)

	
Scan multibranch pipeline



Expected result:


No changes detected: master (still at 835d8b37)


Actual result:


Changes detected: master (f264be47 → 835d8b37)


Scheduled build for branch: master


 


The same steps produced the following result when testbranch-1 was merged into testbranch-2 (essentially between two non-named branches):


Changes detected: testbranch-2 (null → 39fb6587)


No automatic build triggered for testbranch-2

• environment: Jenkins version 2.190.3, Branch API version 2.5.4, Bitbucket Branch Source version 2.4.6

1 attachment

- [bitbucketprojectdsl.groovy](https://issues.jenkins.io/secure/attachment/50149/bitbucketprojectdsl.groovy)

Review the attached bitbucketprojectdsl.groovy job setup, then reproduce the behavior through a multibranch pipeline scan using the listed Jenkins, Branch API, and Bitbucket Branch Source versions. Done means a manually built master commit is recognized during scanning without scheduling another build, while the non-named branch behavior remains understood.

Written by the indexing model from the issue text.