I've been using this plugin for quite a while now and it is great to juggle the time lags between a code change and build artifact on a busy server.

However I've come to realize one annoyance: when a pull request gets merged, other open PRs are (by web-hook or eventually by a Branch Indexing rescan) triggered to build against the updated target branch, using an ephemeral commit as calculated by Git. This is good per se, we want to know those PRs are still valid and mergeable by the time we decide to accept them. What is missing is a way to queue them at a different priority (so they do not compete and win against other PRs that are actively worked on and their source codebases are updated).

So this RFE is about somehow differentiating "PR-merge" vs. "PR-head" build causes for tweaking the "Priority Strategy" in "Use additional rules when assigning a priority to a job" - so that "PR-merge" builds can, in our case, be a background noise - only taking place if no more interesting jobs are queued/running.