fix(ci): fail the tinystudio.in deploy lane loudly when Pages secrets are missing - #131
Conversation
… are missing Replace the green 'dormant' step (which exited 0 when CLOUDFLARE_API_TOKEN / CLOUDFLARE_ACCOUNT_ID were absent, making every main merge report a deploy while production stayed stale) with a fail-closed step that prints the provisioning steps and exits 1. Green now means 'deployed and verified': the publish step still runs check-public-live-deploy.mjs after upload and fails the run when the live acceptance fails, and the run can no longer succeed without running it. Add scripts/test-deploy-public-site-workflow.mjs (hermetic, wired into npm test and npm run ci) asserting the fail-closed contract: no dormant step, a fail-loud step gated on missing secrets, deploy steps gated on both secrets, acceptance script in the deploy path. Red on the old workflow (dormant step), green on the new one.
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
There was a problem hiding this comment.
Your trial has ended. Reactivate Greptile to resume code reviews.
|
Warning Review limit reached
Next review available in: 46 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 (3)
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.
1 participant
What
The deploy lane's 'dormant' step printed provisioning steps and exited 0 when
CLOUDFLARE_API_TOKEN/CLOUDFLARE_ACCOUNT_IDwere absent from repo secrets. Every main merge therefore reported a green deploy run while production stayed stale (live acceptance currently fails 6/13 checks).Change
exit 1when either required secret is missing.check-public-live-deploy.mjsafter upload and fails the run on acceptance failure; the run can no longer go green without running it.scripts/test-deploy-public-site-workflow.mjs(wired intonpm test/npm run ci): red on the old dormant workflow, green on the fail-closed one.Proof
node scripts/test-deploy-public-site-workflow.mjson the pre-change workflow: 3 failures, exit 1; on this branch: 10 checks, 0 failures, exit 0.node scripts/test-public-deploy-bundle.mjs: 0 failures.node --checkall scripts: 0.npm run cifails only on the pre-existingcheck-retention-automation.mjsenvironment issue (identical failure on a pristine origin/main worktree — automation.toml points at a different checkout; unrelated to this change).Note
No Pages-capable Cloudflare token exists anywhere yet (fleet token tested live: Pages API error 10000; no token in any repo/environment secret). Until
gh secret set CLOUDFLARE_API_TOKEN -R nish3451/tinystudio-inis done, the lane runs red — that is the intended truthful behavior; the nightly live-site-check.yml remains the staleness alarm.