fix(ops): keep the public deploy lane green until the Pages token is provisioned - #85
fix(ops): keep the public deploy lane green until the Pages token is provisioned#85nish3451 wants to merge 2 commits into
Conversation
…provisioned The release lane (PR #70/#81) is fail-closed on CLOUDFLARE_API_TOKEN, but the repo has no secrets at all, so every push to main produces a permanently red 'Deploy public site' run that is indistinguishable from a real deploy failure. Gate the publish step on the secrets actually existing (step-level if, where the secrets context is available): while absent, the step is skipped and a notice step prints the exact provisioning steps, keeping the lane visibly dormant; the pre-deploy and bundle-prepare gates still run on every merge. The moment both secrets exist the lane publishes and fails loudly on any deploy/verify error, preserving fail-closed behavior once provisioned. Direct manual runs of publish-public-site.mjs remain fail-closed (the script is unchanged). verify: yaml syntax parse; git diff --check
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
There was a problem hiding this comment.
nish3451 has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.
|
Warning Review limit reached
Next review available in: 6 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: Pro Plus Run ID: 📒 Files selected for processing (1)
Comment |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 758eead1c7
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
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".
| run: node scripts/publish-public-site.mjs --prepare-only --output "$RUNNER_TEMP/tinystudio-public-bundle" | ||
|
|
||
| - name: Publish to Cloudflare Pages and verify live | ||
| if: ${{ secrets.CLOUDFLARE_API_TOKEN != '' && secrets.CLOUDFLARE_ACCOUNT_ID != '' }} |
There was a problem hiding this comment.
On every push or manual dispatch, GitHub rejects this step condition because the secrets context is unavailable in jobs.<job_id>.steps.if; the dormant notice uses the same unsupported context, so this change makes the release workflow fail validation rather than keeping it green. GitHub's workflow syntax documentation explicitly says secrets cannot be referenced directly in if: conditionals and recommends assigning them to job-level environment variables before testing env.* instead.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
nish3451 has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.
…very main merge while the Pages token is missing (#111) The deploy lane has been failing every main push since PR #81 landed: without CLOUDFLARE_API_TOKEN / CLOUDFLARE_ACCOUNT_ID the publish step throws after a full npm ci + check + prepare cycle (~6 minutes), leaving the live site permanently stale on the June-20 bundle. PR #85 attempted to gate the publish step on the secrets, but its step-level `if: ${{ secrets... != '' }}` conditions are invalid - the secrets context is not available in step-level if conditions (context availability table), so the workflow failed validation and never ran. Hoist both secrets into the job-level env (where the secrets context is allowed) and gate every expensive step with `if: env.X != ''`: - Dormant (no secrets): seconds-long green run printing the exact one-time provisioning steps as a warning annotation. - Active (both secrets set): unchanged fail-closed publish + live verification on every main merge; the moment the token is provisioned the lane deploys without any code change.
|
Closing — 1. 2. The condition here would not work. This PR gates the publish step with 3. The provisioning guidance already landed. Separately, and worth flagging: |
1 participant
Why
The tinystudio.in release lane (from PR #70, landed via #81) is fail-closed on the
CLOUDFLARE_API_TOKENsecret. That secret does not exist — the repo currently has zero secrets (gh api .../actions/secrets→ total_count 0) — so every push to main produces a permanently redDeploy public siterun:A lane that can never pass is worse than no lane: the red run is indistinguishable from a real deploy failure, and it drowns the signal the lane exists to provide.
What
Gate the publish step on the secrets actually existing. Step-level
ifis used because the secrets context is not available at job level:f670a698e17bf160c8e4679823e68916→gh secret set×2). The lane is visibly dormant, never red.npm run check) and the filtered bundle prepare step, so the lane stays warm and the bundle stays regression-guarded.The publish script (
scripts/publish-public-site.mjs) is unchanged: direct/manual runs without a token still print the provisioning message and exit non-zero.Verify
python3 -c 'import yaml; yaml.safe_load(open(...))'→ oknode scripts/test-public-deploy-bundle.mjs→ passesgit diff --check→ cleanDeploy public sitewith the publish step skipped and the notice annotation instead of a failure.