[abrichr]

Why

Packages runs on main were never cancelled, so every push queued a full run behind the previous ones.

Baseline over the last 24 completed main push runs (medians):

Metric	Value
Wall time	51.3 min
Job queue wait	14.1 min
Longest job wait in a run	18.9 min
Jobs per run	11
Runner-minutes per run	66

In the last 48 hours main got 137 first-parent pushes. Only 12 of them changed packages/desktop.

The only reader that needs a particular main commit's own Packages run is desktop-release.yml. It waits for the push run of the newest first-parent commit that changed packages/desktop (#1398).

What changes

packages.yml concurrency:

• Pull requests: unchanged. A newer push supersedes the older run.
• A push to main whose payload mentions packages/desktop/ (any commit's file lists, or even a message): keeps its own packages-<sha> group and is never cancelled.
• A push without a commit list: also keeps its own group and is never cancelled.
• Every other push to main: shares packages-main-without-desktop with cancel-in-progress, so a newer push cancels the older run.
• Merge queue groups and dispatches: per-SHA and never cancelled.

The Desktop test is deliberately conservative. A false "Desktop" match only means a run isn't cancelled.

tests/test_packages_concurrency.py keeps the Desktop exception, the per-SHA fallback, and the rule that queue and dispatch runs are never cancelled.

Savings

I replayed the last 48 hours of first-parent push times against the 51-minute median run:

• 112 of the 125 non-Desktop pushes were superseded before their run would have finished, so they would now be cancelled.
• That's up to 112 × 66 ≈ 7,400 runner-minutes over 48 hours. It's an upper bound, since a cancelled run has usually done some work.
• More importantly, those runs no longer hold the 20 job slots (5 macOS) that PR runs wait for. I'll post measured queue medians after a day of main traffic.

What this gives up

A non-Desktop commit that is superseded within the hour no longer gets its own green or red result on main; the next commit's run covers the same tree plus more. With the merge queue (#1412), each group is tested before it lands.

Coordination

I've told the session moving the release trigger to workflow_run. workflow_run also fires for cancelled runs, so that trigger should act only on a successful run for a Desktop-changing first-parent commit. This PR changes no release workflow, and never cancels a release run or the run for a Desktop-changing commit.

Verified

• The workflow parses.
• tests/test_packages_concurrency.py and tests/test_desktop_release_subject.py pass.

🤖 Generated with Claude Code

[abrichr]

Update: a push with 20 or more commits now keeps its own group and is never cancelled. GitHub truncates the push payload's commit list at 20, which could hide a packages/desktop change. The guard is !github.event.commits[19], in both group and cancel-in-progress, and tests/test_packages_concurrency.py requires it. Compatible with #1414: workflow name, job prefixes and Desktop-push behavior are unchanged.