Repository navigation
Conversation
A run's priority decides which queued run is claimed first, and any person allowed to run a job or rerun could set any priority. A person's job run or rerun above priority 0 now also needs run.prioritise on the run's nodes. Only Admin grants it among built-in roles, project roles may grant it, and it has no default role. Priority 0 and below need nothing extra, and trusted local launches are unchanged.
Only queueing a job run or a rerun above priority 0 needs run.prioritise. Cancelling an urgent run keeps needing only run.cancel.
kvlonge
enabled auto-merge (squash)
November 8, 2026 18:38
Contributor
Author
|
Folded into the single combined sqlbuild PR (D625/D626), which the SQLBuild lane is assembling now and opens once #1377 lands. Branch kept. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
A run's priority decides which queued run is claimed first. Any person allowed to run a job or rerun could set any priority, and so move their run ahead of everyone else's. Moving ahead of the queue is now its own permission.
Changes
run.prioritise. A person's job run or rerun with a priority above 0 also needs it, on the same nodes as the run's other permissions. Priority 0 and negative priorities need nothing extra.sqb location, schedules) are unchanged.No DuckShop project case: this is a permission rule. The orchestration role matrix in DuckShop's edge-case area gains the expected outcome per built-in role.
Verification
test_person_sessionson SQLite and PostgreSQL: a priority-1 job run is refused for no role, Viewer, Operator and Developer and accepted for Admin, and the listed run keeps its priority.svelte-check,vitest,make check-ci.