[JENKINS-72367] RFE: Allow to differentiate PR "merge" vs. "head" re-builds for priority sorting

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.

---
Originally reported by jimklimov, imported from: RFE: Allow to differentiate PR "merge" vs. "head" re-builds for priority sorting

• status: Open
  
• priority: Minor
  
• component(s): prioritysorter-plugin
  
• resolution: Unresolved
  
• votes: 0
  
• watchers: 1
  
• imported: 20251211-071809
  

Raw content of original issue

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.

environment

```
Jenkins LTS 2.426.1

Priority Sorter 5.0.0
```

Start by reading the Priority Strategy configuration and the plugin's handling of pull-request build causes. Determine how PR-merge and PR-head builds can be distinguished for additional priority rules, and verify that merge-triggered builds can be assigned a lower or background priority without changing head-build behavior.

Written by the indexing model from the issue text.