Skip to content

fix(cloud): enable tag-to-deploy for production cloud worker #1735

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
jchris wants to merge 1 commit into
base: main
Choose a base branch
from
+19 −1
Open

fix(cloud): enable tag-to-deploy for production cloud worker #1735

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions .github/workflows/ci-core-cf-deploy.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -42,6 +42,7 @@ jobs:
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 }}
Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot Apr 3, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

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:deploy
diff --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.

Copy link
Copy Markdown
Contributor Author

@jchris jchris Apr 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot Apr 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Copy Markdown

@chatgpt-codex-connector chatgpt-codex-connector Bot Apr 3, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Pass deployment env to cf-storage-cors step

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 👍 / 👎.

Copy link
Copy Markdown
Contributor Author

@jchris jchris Apr 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

FP_ENDPOINT: ${{ vars.FP_ENDPOINT }}
STORAGE_URL: ${{ vars.STORAGE_URL }}
run: |
Expand Down
2 changes: 1 addition & 1 deletion cloud/backend/cf-d1/package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,7 @@
"publish": "echo skip",
"drizzle:d1-local": "drizzle-kit push --config ./drizzle.cloud.d1-local.config.ts",
"drizzle:d1-remote": "drizzle-kit push --config ./drizzle.cloud.d1-remote.config.ts",
"wrangler:deploy": "wrangler deploy -c ./wrangler.toml --env dev"
"wrangler:deploy": "wrangler deploy -c ./wrangler.toml --env ${CLOUDFLARE_ENV:-dev}"
},
"keywords": [
"ledger",
Expand Down
17 changes: 17 additions & 0 deletions cloud/backend/cf-d1/wrangler.toml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -79,3 +79,20 @@ binding = "FP_BACKEND_D1"
database_name = "fp-cloud-dev"
database_id = "b0c1ea22-b733-420c-b812-bea9ffaa1676"

[env.production.vars]
VERSION = "FP-MSG-1.0"

[[env.production.migrations]]
tag = "v1"
new_classes = ["FPRoomDurableObject"]

[env.production.durable_objects]
bindings = [
{ name = "FP_WS_ROOM", class_name = "FPRoomDurableObject" }
]

[[env.production.d1_databases]]
binding = "FP_BACKEND_D1"
database_name = "fp-cloud-production"
database_id = "ee23476b-c3c8-44c9-8388-d9455dd1b00f"

Loading