Priority
Control the order pull requests are tested and merged in the Merge Queue
When a high-priority change must be merged quickly but still validated by the Merge queue, you can use PR Prioritization to create a PR that goes through the queue faster than others.
Setting Priorities
You specify a custom priority for a pull request at the time on insertion into the queue:
or
valid values for the priority level:
| label | number | note |
|---|---|---|
urgent | 0 | urgent items will interrupt running jobs and begin testing immediately |
high | 10 | |
medium | 100 | default priority |
low | 200 | |
255 | lowest possible priority |
How Priority Affects PR Order
PRs with a higher priority will always begin testing before any other PR that isn't currently being tested, ensuring that prioritized PRs move into the queue as soon as they can. A PR without a priority will use the default medium (100) priority. If there is already a PR in the queue with the exact same priority then the new one will be behind it.
When prioritizing a PR, Merge will explicitly not interrupt any currently testing PR, as it is usually costly to restart testing on PRs even if you want another PR to be sooner. Because of this, if a PR is submitted with a priority and there is still room in the queue to begin testing PRs, it will being testing as normal without interrupting other PRs.
There is one exception to this rule. Sometimes, when there is a PR urgent enough to get in that it is worth the cost of restarting a currently testing PR, you can move the new PR to the front using the "urgent" priority. This is the only time Merge will reschedule a PR that is already in testing.
Example:
Say you have a queue that is configured to test two PRs at once. The queue currently looks like this:
If you submit a PR D with a "high" priority it will be put in front of C (since it is a higher priority than C and C is not testing). D will begin as soon either A or B finishes, like this:
If instead you submit PR D with an "urgent" priority, then D would be tested immediately, A would be restarted, and B would be bumped back to pending, like this:
Last updated
