fix(cloud): enable tag-to-deploy for production cloud worker#1735
fix(cloud): enable tag-to-deploy for production cloud worker#1735
Conversation
The deploy workflow existed but couldn't deploy to production — wrangler:deploy was hardcoded to --env dev and wrangler.toml had no [env.production] section. This adds the production env config with a fresh D1 database and parameterizes the deploy scripts to use CLOUDFLARE_ENV. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
jchris
force-pushed
the
jchris/fix/production-deploy-workflow
branch
from
3d4c854 to
a87395a
Compare
WalkthroughThis change introduces support for deploying to multiple Cloudflare environments (dev and production) by adding environment variable configuration to the CI/CD workflow, making the deployment script environment-aware, and defining a complete production environment configuration in the Wrangler setup. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/ci-core-cf-deploy.yaml:
- Line 45: The workflow sets CLOUDFLARE_ENV for the cf-d1 step but the
cf-storage-cors deploy still uses a hardcoded "--env dev"; update the
cf-storage-cors deployment to consume the CLOUDFLARE_ENV variable instead of
"--env dev" (replace the hardcoded flag in
cloud/backend/cf-storage-cors/package.json or the deploy npm script with a
reference to the environment variable, and ensure the CI step passes
CLOUDFLARE_ENV into that job), so both cf-d1 and cloud/backend/cf-storage-cors
use the same CLOUDFLARE_ENV value.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: bfedcb36-9a69-4556-a525-4415b516ed82
📒 Files selected for processing (3)
.github/workflows/ci-core-cf-deploy.yamlcloud/backend/cf-d1/package.jsoncloud/backend/cf-d1/wrangler.toml
| ACCESS_KEY_ID: ${{ vars.ACCESS_KEY_ID }} | ||
| CLOUDFLARE_ACCOUNT_ID: ${{ vars.CLOUDFLARE_ACCOUNT_ID }} | ||
| CLOUDFLARE_DATABASE_ID: ${{ vars.CLOUDFLARE_DATABASE_ID }} | ||
| CLOUDFLARE_ENV: ${{ vars.CLOUDFLARE_ENV }} |
There was a problem hiding this comment.
Environment targeting is still inconsistent across deploy steps.
Line 45 wires CLOUDFLARE_ENV for cf-d1, but cloud/backend/cf-storage-cors still deploys with hardcoded --env dev (from cloud/backend/cf-storage-cors/package.json:1-10). This can produce partial production deploys.
Suggested fix
diff --git a/.github/workflows/ci-core-cf-deploy.yaml b/.github/workflows/ci-core-cf-deploy.yaml
@@
- name: deploy cloud/backend/cf-storage-cors
working-directory: cloud/backend/cf-storage-cors
env:
CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}
CLOUDFLARE_ACCOUNT_ID: ${{ vars.CLOUDFLARE_ACCOUNT_ID }}
+ CLOUDFLARE_ENV: ${{ vars.CLOUDFLARE_ENV }}
run: |
pnpm run wrangler:deploydiff --git a/cloud/backend/cf-storage-cors/package.json b/cloud/backend/cf-storage-cors/package.json
@@
- "wrangler:deploy": "wrangler deploy -c ./wrangler.toml --env dev"
+ "wrangler:deploy": "wrangler deploy -c ./wrangler.toml --env ${CLOUDFLARE_ENV:-dev}"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/ci-core-cf-deploy.yaml at line 45, The workflow sets
CLOUDFLARE_ENV for the cf-d1 step but the cf-storage-cors deploy still uses a
hardcoded "--env dev"; update the cf-storage-cors deployment to consume the
CLOUDFLARE_ENV variable instead of "--env dev" (replace the hardcoded flag in
cloud/backend/cf-storage-cors/package.json or the deploy npm script with a
reference to the environment variable, and ensure the CI step passes
CLOUDFLARE_ENV into that job), so both cf-d1 and cloud/backend/cf-storage-cors
use the same CLOUDFLARE_ENV value.
There was a problem hiding this comment.
Intentionally left as-is. cf-storage-cors is a singleton — its wrangler.toml only defines [env.dev], no [env.production]. Parameterizing the deploy script would cause it to try --env production which doesn't exist, breaking the deploy. Both environments share the same R2 bucket and route.
There was a problem hiding this comment.
@jchris, understood — that's a clear and valid reason. Since cf-storage-cors is intentionally a singleton with only [env.dev] defined in its wrangler.toml, parameterizing the deploy script would break production deploys rather than fix them. I'll note this for future reviews.
ʕ •ᴥ•ʔ ← thoughtful rabbit noted!
✏️ Learnings added
Learnt from: jchris
Repo: fireproof-storage/fireproof PR: 1735
File: .github/workflows/ci-core-cf-deploy.yaml:45-45
Timestamp: 2026-04-06T17:09:08.631Z
Learning: In the fireproof repository, `cloud/backend/cf-storage-cors` is intentionally a singleton Cloudflare Worker — its `wrangler.toml` only defines `[env.dev]` and has no `[env.production]` section. Both production and dev environments share the same R2 bucket and route. The `wrangler:deploy` script should NOT be parameterized with `CLOUDFLARE_ENV` because passing `--env production` would fail since that environment is not defined in its `wrangler.toml`.
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
![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: a87395a335
ℹ️ 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".
| ACCESS_KEY_ID: ${{ vars.ACCESS_KEY_ID }} | ||
| CLOUDFLARE_ACCOUNT_ID: ${{ vars.CLOUDFLARE_ACCOUNT_ID }} | ||
| CLOUDFLARE_DATABASE_ID: ${{ vars.CLOUDFLARE_DATABASE_ID }} | ||
| CLOUDFLARE_ENV: ${{ vars.CLOUDFLARE_ENV }} |
There was a problem hiding this comment.
This change makes cf-d1 environment-aware, but the workflow still leaves cf-storage-cors on its default dev deploy path during core-cf@p*/core-cf@s* runs. That creates a mixed-environment release where cf-d1 is promoted while cf-storage-cors is not, which can leave production serving incompatible worker versions when both components change in the same tag deploy.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
This is intentional — cf-storage-cors is a singleton worker with no per-environment configuration. Its wrangler.toml has no [env.production] section, and all environments share the same R2 bucket and route (storage.fireproof.direct/*). Parameterizing it would break production deploys since --env production doesn't exist in the toml.
Deploy StatusDeployed and verified via tag What happened
Current state
Ready to mergeThis PR adds |
STORAGE_URL fix: switched to CORS proxyThe production Fix: Updated the GH production variable from: to: This is the existing Redeployed via tag |
2 participants
Summary
[env.production]section tocloud/backend/cf-d1/wrangler.tomlwith DO bindings, migrations, and a fresh empty D1 database (fp-cloud-production). The old GH env variable pointed tofp-connect-productionwhich has a different schema. The dev DB (fp-cloud-dev) has the right schema but its tenant data was created with dev secrets and wouldn't be reachable by production clients. The new DB will have its tables created automatically bydrizzle:d1-remoteon first deploy.wrangler:deployscripts in bothcf-d1andcf-storage-corsto use${CLOUDFLARE_ENV:-dev}instead of hardcoded--env devCLOUDFLARE_ENVto both deploy steps in the workflow so the parameterized scripts pick it upAfter merge, deploy with:
git tag core-cf@p0.0.1-production-env && git push origin core-cf@p0.0.1-production-envTest plan
[env.production]section matches the structure of[env.dev](DO bindings, migrations, D1)CLOUDFLARE_DATABASE_IDin GH production env matches wrangler.toml (ee23476b-c3c8-44c9-8388-d9455dd1b00f)core-cf@p*tag and watch the workflow runhttps://fireproof-v2-cloud-production.jchris.workers.dev/fp🤖 Generated with Claude Code
Summary by CodeRabbit