ci: run the artifact workflow on push to main - #191
Conversation
Nothing verifies main. `cloud-runtime-artifact.yml` triggered only on `pull_request` and `workflow_dispatch`, and `review-swarm.yml` only on `pull_request` -- so a PR is checked at its own head and never as merged. That gap is not theoretical. Twelve PRs merged on 2026-09-05, all in interacting areas -- the exactly-once claim path (#171, #182), resume adoption (#177, #186), the authored-flow executor (#184, #187), the CLI run loop (#180) -- each green on its own branch, and the composed tree never run until I dispatched it by hand tonight: run 33987924703 workflow_dispatch main completed/success ed917bf Main is fine. But nobody knew that, and finding out required knowing to ask. Without this, a bad compose surfaces as an UNRELATED PR going red, which is the most expensive way to find it: the author debugs their own change first, then the base, then eventually the merge that broke it. Tonight already produced three separate cases of a failure on one PR belonging to something else entirely (#179, #185, and the #174 chain), and each cost a tick to attribute. Paths are deliberately not filtered on the push trigger. On a PR the question is "does this change affect the runtime"; on main it is "is the tree good", and a docs-only merge can still land on a tree that someone else broke. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FtQSAcGDta5VH9xiZFT4sR Session-Id: c228933d-4f94-4d83-9a9a-daf3c83b94f1
|
Warning Review limit reachedNext included review available in 6 minutes. View limit detailsLimit details: You’ve used the included review currently available. Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. Review configuration: ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Free Run ID: 📒 Files selected for processing (1)
Note 🎁 Summarized by CodeRabbit FreeYour organization is on the Free plan. CodeRabbit will generate a high-level summary and a walkthrough for each pull request. For a comprehensive line-by-line review, please upgrade your subscription to CodeRabbit Essentials by visiting https://app.coderabbit.ai/settings/billing. Comment |
…in verified green Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FtQSAcGDta5VH9xiZFT4sR Session-Id: c228933d-4f94-4d83-9a9a-daf3c83b94f1
Nothing verifies main
cloud-runtime-artifact.ymltriggered only onpull_requestandworkflow_dispatch;review-swarm.ymlonly onpull_request. So every PR is checked at its own head and never as merged — and since we squash-merge onto a main that has moved since that CI ran, the composed result goes unverified.Not theoretical
Twelve PRs merged on 2026-09-05, all in interacting areas — the exactly-once claim path (#171, #182), resume adoption (#177, #186), the authored-flow executor (#184, #187), the CLI run loop (#180). Each green on its own branch. The composed tree was never run until I dispatched it by hand tonight:
Main is fine. But nobody knew that, and finding out required knowing to ask.
Why it is worth a trigger rather than a habit
Without this, a bad compose surfaces as an unrelated PR going red — the most expensive way to find it, because the author debugs their own change first, then the base, then eventually the merge that broke it.
Tonight produced three separate cases of a failure on one PR belonging to something else entirely (#179, #185, and the #174 chain), and each cost a tick to attribute. Those were all pre-existing rather than compose failures, but they are the same debugging shape.
Note on paths
Deliberately not filtered on the push trigger. On a PR the question is "does this change affect the runtime". On main it is "is the tree good" — and a docs-only merge can still land on a tree someone else broke.
🤖 Generated with Claude Code
https://claude.ai/code/session_01FtQSAcGDta5VH9xiZFT4sR