ExportXMLWordPrintable

      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:

       

      1. PR A and PR B are both open against master, both green.
      2. 2. PR A is added to the merge queue and merges, advancing master.
      3. 3. PR B is ejected from the queue (as expected, since it needs to be re-validated against the new master).
      4. 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. 5. PR B's Jenkins build status therefore stays stale-GREEN, and Bitbucket's "Add to merge queue" button remains enabled for it.
      6. 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

            Assignee:
            Unassigned
            Reporter:
            aviad
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated: