fix(ci): stop main web runs from queueing behind unapproved runs - #14546
Conversation
The workflow-level concurrency group keyed on github.ref, so every push to main landed in the same group. A run parked at the production/release approval gate keeps the run "in progress" for as long as it waits, holding the group — the next push sat pending behind it, and the push after that cancelled the pending run before it ran a single job. Recent main runs show exactly this: several parked 40-100+ hours at the gate, and newer runs cancelled after 11-22s with zero jobs executed. Fall back to github.run_id instead of github.ref when head_ref is empty, so each main run gets its own group and runs independently. PR behavior is unchanged: still keyed on the branch, still cancels superseded runs. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
|
Dependency limit exceeded — report not shown. This pull request scan exceeded the 10,000-dependency limit applied to this scan, so the results are incomplete and may be inaccurate. To avoid reporting false positives, Socket has not posted a report. Upgrade your plan to raise the dependency limit and get complete reports, or view the partial scan in the dashboard. Socket is always free for open source. If this is a non-commercial open source project, contact us to request a free Team account. |
Problem
Web CI on
mainregularly gets stuck. The workflow-level concurrency group was:On
main,head_refis empty, so every push landed in the same group (web-refs/heads/main), andcancel-in-progressisfalsefor pushes.A job waiting at the
productionorreleaseenvironment approval gate keeps its run in progress for as long as it waits — holding the group. So:Recent
mainrun history shows both halves of this:GET /actions/runs/30865573872/jobsreturns an empty job list, confirming those short runs never started a single job; they were evicted while pending.Fix
Fall back to
github.run_idinstead ofgithub.refwhenhead_refis empty, so eachmainrun gets its own concurrency group and runs independently. A run parked at an approval gate can no longer block or evict the next push, and an in-flight deploy is never interrupted.PR behavior is unchanged: still keyed on the branch, still cancels superseded runs on new commits.
Trade-offs
mainnow runs full CI on every push instead of evicting queued runs, so spend rises slightly versus today's broken behavior. The alternative —cancel-in-progress: trueonmain— would let a new push kill an in-flight production deploy, which is worse.web-deploywould close it, but that's out of scope here.identity.ymlandsdk.ymluse the samegithub.refpattern but have no environment gates, so nothing can park there — left unchanged.🤖 Generated with Claude Code