chore(ci): deploy the dashboard agent dormant, drop the reviewer gate, add a ref input - #4710
Conversation
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 10 included reviews per hour; 5 remain after this review. 📜 Recent review details⏰ Context from checks skipped due to timeout. (2)
🔇 Additional comments (2)
WalkthroughThe deployment workflow documents dormant per-environment deployments and environment-scoped tokens. Manual runs accept an optional commit, branch, or tag ref. Checkout uses the supplied ref when present and 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
14e3cdd to
d93ff13
Compare
d93ff13 to
e65e60e
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 4544b967-b6f1-425c-838f-d92a94aeab8b
📒 Files selected for processing (1)
.github/workflows/dashboard-agent-deploy.yml
Included review availability: Your plan provides up to 10 included reviews per hour; 6 remain after this review.
📜 Review details
⏰ Context from checks skipped due to timeout. (3)
- GitHub Check: code-quality / code-quality
- GitHub Check: Zizmor
- GitHub Check: Analyze (javascript-typescript)
🔇 Additional comments (2)
.github/workflows/dashboard-agent-deploy.yml (2)
6-14: LGTM!Also applies to: 27-31, 65-70, 81-83
49-53: Resolve the cancellation-policy mismatch.The PR objective says
cancel-in-progress: true, but the workflow retainscancel-in-progress: false. The comments intentionally document the opposite behavior. Confirm which contract is required. If cancellation is required, add provider-side cancellation or locking before changing this value.
…, add a ref input The agent deploys with --skip-promotion, so a deploy lands dormant and nothing goes live until DASHBOARD_AGENT_VERSION is flipped. The per-environment reviewer gate therefore bought nothing but a pile-up: every agent-path merge queued a staging+prod deploy that sat pending on an approval nobody granted, and the runs cancelled each other while the actual deploy only ever happened via a manual dispatch + approval. Remove the gate by dropping the required-reviewers rule on the dashboard-agent-* environments (a repo-settings change; the environment: key stays so the scoped deploy token still resolves), and add a workflow_dispatch ref input to deploy a specific commit, branch, or tag when needed. The ref must be an ancestor of main: the deploy token runs the checked-out build and trigger.config.ts, so only reviewed, merged code may run with it. A push is always main's tip; a dispatched ref is checked before deploy. Concurrency keeps cancel-in-progress: false, because cancelling the runner wouldn't stop the remote build and a superseding concurrent deploy would race the same project's indexer; with the gate gone deploys are short, so queueing can't pile up.
e65e60e to
074e239
Compare
Problem
Every merge to main touching the agent queued a gated
staging+proddeploy that satpendingon a reviewer approval nobody grants routinely. Because the gated runs never completed, they never drained the concurrency queue and cancelled each other, so the Actions tab filled with never-completing runs and the agent only ever actually deployed via a manual dispatch + approval.The reviewer gate bought nothing here: the agent deploys with
--skip-promotion, so a deploy lands dormant and nothing goes live until the consuming webapp flipsDASHBOARD_AGENT_VERSION. Promotion is already a deliberate act (the env-var flip); gating the dormant deploy on top of that just created the pile-up.Change
dashboard-agent-*environments (repo-settings change, done). Theenvironment:key stays so the per-environment scoped deploy token still resolves — no secret migration.workflow_dispatchrefinput — deploy a specific commit SHA, branch, or tag; defaults to the ref the run launches from. Checkout usesgithub.event.inputs.ref || github.sha.main. Constrains which commit gets deployed to merged code only. A push is always main's tip (passes trivially); a dispatched unmerged ref is rejected before the deploy step. Because an explicitref:checkout doesn't create remote-tracking branches,origin/mainis fetched explicitly beforegit merge-base --is-ancestor.cancel-in-progress: false(kept). Cancelling the runner wouldn't stop the remote build (it finishes server-side), and a superseding concurrent deploy would race the same project's indexer. With the gate gone, deploys are short, so a brief queue can't pile up.max-parallel: 1stays (parallel deploys of the same project race at the indexer).Owner actions (repo settings — not in the diff)
dashboard-agent-staginganddashboard-agent-prod— done.main. This is the authoritative token guard:workflow_dispatchruns the workflow file from the selected ref, so the in-file ancestor check alone can't protectTRIGGER_ACCESS_TOKEN(a branch could edit the check out). GitHub enforces the branch policy server-side againstGITHUB_REFregardless of file contents. With it in place, the workflow only runs (and the token is only exposed) when dispatched frommain, and the in-file check then constrains the independentrefinput to merged commits.Pile-up root cause
The stacking was caused by the reviewer gate (runs waited forever, so the queue never drained), not by
cancel-in-progress. Removing the gate is what fixes it;cancel-in-progressstaysfalse.