fix(ci): fail the tinystudio.in release lane truthfully on missing secrets and roll back bad uploads - #130
Conversation
…crets and roll back bad uploads The deploy-public-site.yml lane previously exited green while the Pages token was missing (a dormant notice step), so main merges reported a green deploy status for a skipped publish. The lane now fails loudly when either required secret is absent. scripts/publish-public-site.mjs now: - captures the current production deployment identity (canonical Pages deployment id/url/source commit) before upload and refuses to deploy when no safe rollback target can be proven; - restores the exact previous production deployment via the Cloudflare Pages rollback API when post-upload acceptance fails, re-verifies the restored identity, re-runs the same acceptance, and surfaces any rollback failure loudly; - keeps the upload path unchanged (wrangler pages deploy with commit metadata) and adds injectable fetch/run seams for hermetic tests. scripts/test-pages-release.mjs is a hermetic suite (fake Cloudflare fetch, fake wrangler/acceptance runner) that fails on the old script and proves: missing wiring fails, identity captured before upload, rollback invoked after failed acceptance, restored identity re-verified, success path does not roll back.
|
Warning Review limit reached
Next review available in: 58 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Free Run ID: 📒 Files selected for processing (4)
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 Pro by visiting https://app.coderabbit.ai/login. Comment |
…le PRs #130 + #131) Resolve the draft PR #130 conflict with main after PR #131 merged the fail-closed deploy workflow: - deploy-public-site.yml: keep PR #131's fail-loud missing-secret step, env hoisting and both-secrets gates byte-for-byte; the only deltas are the documented capture/rollback/re-verify contract and the descriptive auto-rollback step name from #130. - package.json: combine both test chains (test-operator-check-strictness, test-deploy-public-site-workflow from main; test-pages-release from #130). - publish-public-site.mjs: rename runAcceptance to verifyLive so the merged test-deploy-public-site-workflow.mjs contract (live verification after deploy via check-public-live-deploy.mjs) holds on the reconciled branch; behavior unchanged.
…le with main after PRs #135/#104/#99/#112/#100/#105) The PR #130 branch had already been reconciled with origin/main through c617364 (PRs #131 + #133/#134/#132/#116). Since then origin/main moved to d4f3ef4 with six more merges (#135 #104 #99 #112 #100 #105). Pull them in so PR #130 can be reviewed against current main without weakening the capture/rollback/reverification implementation or the PR #131 fail-closed missing-secret gate. The merge resolved cleanly: - PR #130 capture/rollback logic (publish-public-site.mjs canonical_deployment, rollbackTo, restored identity re-verify, accept-again) is intact. - PR #130 test file (scripts/test-pages-release.mjs) is intact and wired into the npm ci/test scripts. - PR #131 fail-loud missing-secret workflow step in .github/workflows/deploy-public-site.yml is preserved byte-for-byte. - The new origin/main changes touch operator surfaces and the deploy bundle prep; none of them modify the publish-public-site.mjs rollback contract or the Pages token gate, so there were no conflict markers.
…le after #138/#139) Bring the PR branch up to date with origin/main (a8d4da2) so branch protection (strict, required repo-checks) can clear it for merge. Main-side changes are docs/ops-export surfaces only; the PR's capture/rollback/re-verify implementation, its hermetic regression (test-pages-release.mjs), the workflow fail-closed behavior, and the test wiring are unchanged. Co-authored-by: CommandCodeBot <noreply@commandcode.ai>
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
…on main (#130/#132/#133) (#197) Record the decision for the inbox backlog line (tinystudio-in priority=normal AUG13-16). Investigation shows every item is already in main: - truthful-reversible-pages-release: LANDED via PR #130 (ea9eab2); release lane fails truthfully on missing credentials and rolls back bad uploads (scripts/test-pages-release.mjs passes 38/38). - service-backup-restore-roundtrip: LANDED via PR #132 (4a7f442); restore mode in service-state-backup.mjs. - operator-checks-strict: LANDED via PR #133 (c617364); named operator checks fail on blocked readiness with advisory aliases explicitly named. No code change required; this closes the backlog by recording the decision.
Why
deploy-public-site.ymlreported GREEN runs whileCLOUDFLARE_API_TOKENwas missing: the "dormant" notice step exited 0, and every publish step was skipped viaif:conditions. A skipped publish must never look like a successful deploy.The publish script also had no rollback path: a bad Pages upload could not be undone.
What changed
deploy-public-site.yml): when either required secret (CLOUDFLARE_API_TOKEN/CLOUDFLARE_ACCOUNT_ID) is missing, the run fails loudly with the provisioning steps. The dormant green step is gone.scripts/publish-public-site.mjs): the current production deployment identity (canonical Pages deployment id/url/source commit) is captured first; the lane refuses to deploy when no safe rollback target can be proven.POST .../deployments/{id}/rollback), the restored identity is re-verified, the same acceptance re-runs against it, and any rollback failure surfaces loudly (ROLLBACK FAILED/ROLLBACK VERIFICATION FAILED).scripts/test-pages-release.mjs, wired intonpm test/ci): fake Cloudflare fetch + fake wrangler/acceptance runner; fails on the old script (verified) and proves missing wiring fails, identity captured before upload, rollback invoked after failed acceptance, restored identity re-verified, success path does not roll back.Verification
node scripts/test-pages-release.mjs— 38 checks, 0 failures.npm testparity: the only failure is the pre-existing environmentalcheck-retention-automation.mjs("Automation does not point at the TinyStudio repo" — itsautomation.tomlpoints at a different checkout; fails identically on pristine origin/main). All tests after it, including the new suite, pass;node --checksweep over all scripts passes.node scripts/check-public-live-deploy.mjs— still fails against the stale live site (15 checks / 7 failures), unchanged observation; not weakened.Notes
Until the Pages-scoped token is provisioned, main merges will now fail loudly instead of showing a green skipped publish — that is the intended truthful behavior.