Multibranch: merge PR with target without rebuilding on pushes to target?

Using Jenkins
,
1

We got a (somewhat legacy) multibranch pipeline configured like this:

  • Branch Sources:
    • GitHub, https://github.com/...
    • Behaviors:
      • Discover branches: Exclude branches that are also filled as PRs.
      • Discover pull requests from origin: Merging the pull request with the current target branch revision
  • No Scan repository triggers, so the Periodically if not otherwise run setting is unchecked.

Today we had an issue with our webhook delivery, and as a temporary workaround I decided to enable the “Scan repository periodically” setting with an interval of 30 minutes. Immediately Jenkins went reindexing absolutely everything there was in the repo, including 2 year old PRs:

    Checking pull request #2858
Waiting for GitHub to create a merge commit for pull request 2858.  Retrying 3 more times...
      'Jenkinsfile' found
    Met criteria
Changes detected: PR-2858 (08dedfdccb1c3b6fac3f20ca096b07ea40db818e+05efbc4134688a1da1f49d67361e7a78d8b7dd9f (9a0286d01aaf29f00226f7616b0dbc00eec6810a) → 08dedfdccb1c3b6fac3f20ca096b07ea40db818e+069b95c566d2d8ca9d789e9b91806214d9814909 (214bd3c28f4f3626f95fd27d01d7aadd532812eb))
Scheduled build for branch: PR-2858

Here 08ded is the head of #2858, unchanged since 2023; 05efb is a commit in main from last March, and 069b9 is a commit merged today.

I have only now noticed that the help of Merging ... says:

Discover each pull request once with the discovered revision corresponding to the result of merging with the current revision of the target branch. Note that pushes to the target branch will result in new pull request builds.

, but the job has been configured like this for several months, and I am 100% positive I did not see any rebuilding spikes upon a merge…

We’d reeeeally like to build PRs merged with the target, as this keeps the whole continuous integration process more integrated. And though I get the noble idea behind “push to target will result in rebuild” – for the moment we simply lack the machine resources to keep rebuilding every single open PR whenever something gets merged into main.

Is there any way to keep the merging behaviour without the dread of constant rebuilds?
I know I can make our checkout() get something like pull/${env.CHANGE_ID}/merge, but that won’t affect the pipeline, as it should already be checked out from something by this point. We can probably abuse the load() step, so the pipeline itself boils down to something like

@Library ...
node() {
  checkout()
  pipeline = load('jenkins/pipeline.groovy')
}
pipeline()

with the logic abstracted into pipeline.groovy instead, but something feels extremely off about it.