Repository navigation
ci: gate release PRs behind one Release gate context - #6154
Conversation
release-gate.yml runs on every PR into release, calls Platform, Features, and each optional workflow whose paths the diff touches, and fails its `Release gate` job when any of them fails or is cancelled. The optional workflows drop their own pull_request triggers, so release can require one context that always reports. smoke.yml drops its main PR trigger, which the queue policy test forbids. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Quest start outcome: implemented and opened as a draft, since three decisions are open (see the description). I recommend option one for each: one No ruleset was changed. After the next cut lands on (Written by Claude Opus 5.5) |
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 24 minutes. View limit details
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
@codex review The review started on ready has shown "running" for nearly an hour without a result. (Written by Claude Opus 5.5) |
|
Codex Review: Didn't find any major issues. More of your lovely PRs please. Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
|
Enqueuing at The three decisions in the description (one No ruleset changed. Once the next cut carries (Written by Claude Opus 5.5) |
Move c.yml under release-gate.yml, as #6154 did for every release-PR workflow. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Implements quest/m0/ci/release-gates.md.
Settings the maintainer must change (no ruleset is changed here)
None until the next cut merges into
release. Then:Release gatefrom GitHub Actions (integration 15368), besideCheck. Main ruleset 2420853 already requires onlyCheck, and release already droppedTest.Release gate;editedreruns the gate.Adding it earlier blocks every release PR, because a release PR runs the workflows merged with
release.Summary
PRs into
releaseget one required context,Release gate, instead of a ruleset entry per job..github/workflows/release-gate.ymlruns on every release PR (no path filters). AScopejob diffs the PR withdorny/paths-filterand each optional workflow is called when its paths match; Platform and Features are always called. TheRelease gatejob fails when any call (or the scope) failed or was cancelled; skipped calls pass.pull_requesttrigger; the six without one gainworkflow_call. Their path lists move verbatim into the gate's filter, comments included. Theirclosedguards go too.sh/gh/ts-paths.pynow reads the gate'sts:filter (with a unit test), and the dispatch scope follows it.smoke.ymlloses itspull_requesttrigger. It ran on main PRs, whichsh/gh/queue.test.tsforbids, sojust gh test(nightly) failed onmainsince moq-dev/moq#6046. Merges still run it against the published packages.sh/gh/queue.test.tsasserts the new policy: onlycheck.ymlandrelease-gate.ymltakepull_request, every former release PR workflow is called, each filter, output and condition lines up, the gate needs every job, and the verdict fails on failure or cancellation but passes skips.release, the maintainer adds the context.Why one context: a called workflow's result rolls up every job inside it, so a failed
Platform scopeormoq-ffibuild fails the gate. With per-job contexts, a failed upstream job skips its dependents, and GitHub counts a skipped required check as passing. One context also means renaming a job or adding a workflow never needs a ruleset edit.always()runs the gate even in a cancelled run, so aneditedrerun cannot leave a skipped, passing context on the same commit while it runs.The filter diffs with git (
token: "", full checkout). The REST file list stops at 3,000 files, which a cut can exceed. GitHub's ownpathstrigger filter stops at 300.Decisions
Accepted on the coordinator's AFK delegation (2026-10-20), taking the recommended option for each; not maintainer-confirmed.
Release gatecontext, not a required context per job (the quest's original plan), for the skipped-dependent and rename reasons above. The rejected alternative kept each workflow's own trigger, added a scope job to each path-filtered workflow, and listed about 30 job names in the ruleset.ts-paths.py, at that runner cost.dorny/paths-filterv4.0.3 (pinned SHA), not hand-rolled glob matching. It is maintained and matches globs with picomatch (dot: true), like thepathstriggers it replaces.Public API / wire impact
None. CI only.
Checks
just check origin/main: passjust gh check(actionlint, alert coverage, check-runs): passbun sh/gh/queue.test.ts: pass (failed onmainbefore this, onsmoke.yml)python3 sh/gh/ts-paths.test.py,python3 sh/gh/ts-paths.py: passrelease-gate.ymlbefore a PR intoreleasedoes. The cut that carries it will run it before the ruleset requires it.Follow-ups
release-gate.yml's set instead of listing the optional workflows a second time, but nightly passesbenchmarks: trueto Platform and skips path selection. Not recommended for now.(Written by Claude Opus 5.5)
🤖 Generated with Claude Code