-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
Minor
-
Component/s: atlassian-bitbucket-server-integration-plugin
In a Multibranch Pipeline building pull requests with the "merge with target branch" strategy, an open PR is not automatically rescanned/rebuilt when its target branch (e.g. master) advances - for example, when another PR merges into it.
Â
Only events on the PR's own source branch (or explicit PR events like update/reopen) appear to trigger a rebuild. A push to the target branch does not cause the plugin to re-index or rebuild PRs whose target is that branch, even though the PR's effective merge result (source + new target HEAD) has changed and may now fail to build, fail to merge cleanly, or behave differently than the last recorded build.
Â
Impact with Bitbucket Data Center's native merge queue:
Â
We use Bitbucket DC's built-in merge queue, which requires a green "Pull request" build status (reported by this plugin) before a PR can be merged. The interaction is:
Â
- PR A and PR B are both open against master, both green.
- 2. PR A is added to the merge queue and merges, advancing master.
- 3. PR B is ejected from the queue (as expected, since it needs to be re-validated against the new master).
- 4. Jenkins never rebuilds PR B, because it never receives a trigger for the target-branch push - no webhook/rescan fires for PRs whose target moved.
- 5. PR B's Jenkins build status therefore stays stale-GREEN, and Bitbucket's "Add to merge queue" button remains enabled for it.
- 6. PR B can be re-added to the merge queue and ejected again indefinitely with zero code changes, purely because Jenkins never re-validates it against the moving target.
This defeats the purpose of the merge queue's re-validation step and can let an actually-broken PR appear to keep passing CI.
Â
Expected behavior:
Â
When a target branch a PR points to receives new commits, the plugin should trigger a rescan/rebuild of open PRs targeting that branch (as, e.g., the Bitbucket Branch Source plugin does), so the build status reflects the PR merged against the current target HEAD rather than a stale one.
Â
Related tickets (do not fully cover this):
- JENKINS-72721 - PRs are not merged against target branch when built at all (a related but distinct defect - even the initial build doesn't validate against target)
- -
JENKINS-76186- Closed/Incomplete, about pr:merged not triggering unrelated builds, not target-branch-push triggering re-validation of other PRs