fix(ci): stop the build command from deploying to production - #19
Merged
Conversation
Cloudflare Workers Builds runs `npm run deploy:web` as its BUILD command on every branch, and that script ended in `opennextjs-cloudflare deploy`. So a push to any branch deployed that branch to the production web worker, before review and before merge. This is not theoretical. It fired on 2026-07-27 from the #8 branch, and twice today from throwaway verification branches — each logged "Deployed shiptrack triggers" against the production URL. Until #8 landed, these builds happened to die at `npm ci` on the eslint 10 / eslint-config-next 15 peer conflict, which masked it; that guard is now gone. Deploying is the trigger's own job and it already does it correctly: `wrangler deploy` on main, `wrangler versions upload` (preview, no traffic) elsewhere. The build command only needs to build. So `deploy:web` now just builds, via a new `build:web`, and `npm run deploy` keeps doing a real manual deploy of both workers. The misleading `deploy:web` name is kept deliberately — the trigger config names it, and that config lives in the Cloudflare dashboard, not this repo. A "//deploy:web" note in package.json and a README table explain why, so the next person doesn't help by making it deploy again. Side effect: main deployed twice per merge (build command + deploy command). Now once. Verified: `npm run deploy:web` produces .open-next/worker.js and leaves the production deployment count untouched at 10; `wrangler deploy --dry-run` still resolves the entry point (5880 KiB), so main still ships; poller dry-run unaffected. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Aswincloud-Bot
approved these changes
Aug 14, 2026
Aswincloud-Bot
left a comment
Aswincloud-Bot
left a comment
There was a problem hiding this comment.
Auto-approved: @Aswinmcw is a member of @Aswincloud/admins.
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
shiptrack | 1b9e3be | Commit Preview URL Branch Preview URL |
Aug 14 2026, 10:50 AM |
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ❌ Deployment failed View logs |
shiptrack-poller | 1b9e3be | Aug 14 2026, 10:50 AM |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The problem
Cloudflare Workers Builds runs
npm run deploy:webas its build command, on every branch. That script was:It ends in a production deploy. The trigger it runs under is "Deploy non-production branches" (
branch_excludes: ['main']), so a push to any branch shipped that branch to the production web worker — before review, before merge.Not theoretical. From the #8 branch on 2026-07-27, and twice today from throwaway verification branches:
Today's two were harmless only because those branches were byte-identical to
main. Until #8 landed, these builds died early atnpm cion the eslint 10 /eslint-config-next15 peer conflict, which masked the behaviour — that guard is now gone, and five open dependabot PRs are the likely next trigger (#9 would put Next 16 on production).The fix
Deploying is the trigger's own job, and it already does it correctly:
mainnpm run deploy:webnpx wrangler deploynpm run deploy:webnpx wrangler versions upload(preview, no traffic)So the build command only needs to build:
build:web=opennextjs-cloudflare builddeploy:web=npm run build:web— builds, never deploysdeploy= build +opennextjs-cloudflare deploy+ poller, so a manual full deploy is unchangedpreviewrouted throughbuild:webThe misleading
deploy:webname is kept on purpose: the trigger config names it, and that config lives in the Cloudflare dashboard, not this repo. A"//deploy:web"note inpackage.jsonand a README table explain why, so the next person doesn't "fix" it by making it deploy again.Side effect:
mainwas deploying twice per merge (build command and deploy command). Now once.Verification
Watch this PR's own build: it should log a Version Preview URL and no "Deployed shiptrack triggers" line. That's the fix demonstrating itself.
Still outstanding (dashboard-only, not fixable from the repo)
The poller's "Deploy non-production branches" trigger has deploy command
npx wrangler versions upload, missing-c wrangler.poller.jsonc. Without the flag wrangler readswrangler.jsonc(the web config) and fails on.open-next/worker.js, which the poller'snpm installbuild never generates. That is the red X on the poller for every PR. It is cosmetic — the poller's default-branch trigger deploys correctly on every merge tomain— but it needs the trigger's deploy command changed to:Trigger
cfc489bb-f59e-4f71-a98b-6861180223fc, scriptb5a6adaa33b44418adbb02188e63f879.