feat(cli): auto-update BC channel site URL on deploy#3001
feat(cli): auto-update BC channel site URL on deploy#3001
Conversation
After a successful `catalyst deploy`, automatically update the linked BigCommerce channel's site URL to the new deployment URL so merchants no longer have to remember to do it manually in the control panel. The channel ID is selected interactively at `catalyst project link` / `project create` time (with a "skip" option for users who don't want to link a channel) and persisted to `.bigcommerce/project.json`. At deploy time the resolution order is `--channel-id` flag, then `CATALYST_CHANNEL_ID`, then project.json. Pass `--no-update-channel` to opt out of the auto-update. The deploy first GETs the current channel site and skips the PUT when the URL already matches, and any failure during the update is treated as a soft warning so the deploy itself remains successful — the bundle is already live by the time we hit this step. Adds the `store_channel_settings` scope to the device-OAuth flow; existing logged-in users will need to re-run `catalyst auth login` to pick it up. The new endpoint also requires that scope, so the soft-fail path points users at `catalyst auth login` if they hit a 401/403. Refs LTRAC-446 Co-Authored-By: Claude <noreply@anthropic.com>
Add coverage for the post-deploy channel site URL auto-update introduced in cce879a: - channels.spec.ts: unit tests for fetchChannels, fetchChannelSite (incl. 404→null), and updateChannelSiteUrl, asserting that 401/403 responses surface the re-auth hint. - project.spec.ts: tests the new channel picker in `project link` and `project create` — a selection writes channelId to project.json, the Skip option leaves it untouched, an empty storefront list is handled, and a 403 from the channels API soft-fails so users can still proceed. - deploy.spec.ts: tests the post-deploy update path — successful update, channelId resolution from project.json, the GET-and-skip-when-equal optimization, --no-update-channel as a hard skip, the no-channel-id warning, and the 401 soft-fail with re-auth hint. - tests/mocks/handlers.ts: default `/v3/channels` handler returns an empty list so unrelated tests no longer hit the unhandled-request warning while still exercising the soft-fail path. Refs LTRAC-446 Co-Authored-By: Claude <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
jorgemoya
changed the title
Bundle Size ReportComparing against baseline from No bundle size changes detected. |
The channel picker added in cce879a filtered to type=storefront, which still surfaces non-Catalyst storefronts (Stencil, headless, etc.) that the user can't meaningfully target with `catalyst deploy`. Narrow the filter to platform=catalyst so the picker only shows channels actually backed by Catalyst. Refs LTRAC-446 Co-Authored-By: Claude <noreply@anthropic.com>
…s.ts Move the GET (404) and PUT (success) channel-site MSW handlers used by the post-deploy auto-update tests into the shared handlers.ts so each test only has to override the path it actually exercises. Refs LTRAC-446 Co-Authored-By: Claude <noreply@anthropic.com>
chanceaclark
left a comment
chanceaclark
left a comment
There was a problem hiding this comment.
I think the intention behind this change is good, but I think it might be very destructive and we should probably avoid this. Maybe we can go in the direction that you can pass a flag to do this?
| if (current?.url === deploymentUrl) { | ||
| consola.info(`Channel ${channelId} site URL already up to date (${deploymentUrl}).`); | ||
| } else { | ||
| await updateChannelSiteUrl( |
There was a problem hiding this comment.
This actually might mess up people testing deployments to native hosting and would be very destructive.
For example, I might have channel 123 being deployed via Vercel and I am dual-deploying this to Vercel and Native Hosting, deploying will change the channels site, thus messing up the production deployment.
There was a problem hiding this comment.
Good callout, 100% agree, lets make this work opt in via an explicit flag that needs to be passed when deploying.
Having said that, do we want to remove all logic from project create and project link to add the channel to project.json? Or we keep that and just add the explicit flag?
There was a problem hiding this comment.
I don't think hosting should be tied to a channel.
There was a problem hiding this comment.
I have simplified it considerably by simply having a --update-site-url flag that requires a channelId. Still kept the store_channel_settings oauth scope to allow this for users who are authing via the CLI.
The unknown I have is that once we merge the deployment_hostnames changes, the returned array can contain N urls. How will one select the one they want to update to? Obviously we could default to the first one, but maybe it needs to be user selected?
There was a problem hiding this comment.
What if instead of doing this on the deploy command we have a separate CLI command to manage this? We'd need to think through the UX for it, but I think it might be better than just a flag?
There was a problem hiding this comment.
Hmm, I see your point. I would wait to get the deployment_hostnames work merged first then.
What I would do is a new command that updates the site channel id. It will get all hostnames under the defined project, and then allow the user to select which hostname they want to be used for site url.
There was a problem hiding this comment.
Yeah something like that.
Drop the channel-picker UX added to `project link` / `project create` and the persisted `channelId` in project.json. The auto-update is now driven by a single `--update-site-url <channelId>` flag (or `CATALYST_UPDATE_SITE_URL` env) on `catalyst deploy`: when passed, the deployed URL is PUT to that channel's site after the bundle goes live. Also drop the GET-then-skip-when-equal optimization so the command unconditionally PUTs the deployment URL when the flag is supplied — the caller opted in explicitly, so always make the call. The implementation collapses to: keep `updateChannelSiteUrl`, drop `fetchChannels` and `fetchChannelSite`, and keep the soft-fail (warn + re-auth hint) so a 401/403 doesn't sour an otherwise-successful deploy. Refs LTRAC-446 Co-Authored-By: Claude <noreply@anthropic.com>
Unlighthouse Performance Comparison — VercelComparing PR preview deployment Unlighthouse scores vs production Unlighthouse scores. Summary ScoreAggregate score across all categories as reported by Unlighthouse.
Category Scores
Core Web Vitals
|
2 participants
Jira: LTRAC-446
What/Why?
Adds an opt-in
--update-site-url <channelId>flag (also bound toCATALYST_UPDATE_SITE_URL) tocatalyst deploy. When passed, the CLI PUTs the deployment URL onto the given channel's site (PUT /v3/channels/{id}/site) after the bundle goes live, so merchants no longer have to copy the new URL into the control panel by hand. When the flag is omitted, deploy behaves exactly as before.A few decisions worth flagging for review:
catalyst auth loginhint instead of failing the deploy. The bundle is already live by the time we hit this step, so a non-zero exit would be misleading.store_channel_settingsis added toDEVICE_OAUTH_SCOPES. Existing logged-in users will need to re-runcatalyst auth loginto mint a token with the new scope; the soft-fail catches the 401/403 they would otherwise hit.deployment_urldeprecation. The deployment-status SSE will eventually replacedeployment_urlwithdeployment_hostnames(string array). For this change we keep usingdeployment_urland leave the migration as a commented TODO inDeploymentStatusSchema.Testing
Unit tests:
pnpm --filter @bigcommerce/catalyst test— 141/141 passing (added 4 inchannels.spec.tsforupdateChannelSiteUrl, 3 indeploy.spec.tscovering the new flag).pnpm --filter @bigcommerce/catalyst typecheckandpnpm --filter @bigcommerce/catalyst lintclean.Manual end-to-end (requires a real store + at least one channel):
catalyst auth login— pulls the newstore_channel_settingsscope.catalyst deploy --update-site-url <channelId>— confirm the post-deploy line:Updated channel <id> site URL to https://...and verify in the BC control panel.CATALYST_UPDATE_SITE_URL=<channelId> catalyst deploy— confirm env var is honored.catalyst deploy(no flag) — confirm no channel API call is made.store_channel_settings, runcatalyst deploy --update-site-url <channelId>and confirm the warning +catalyst auth loginhint instead of a crash.Migration
None. The flag is purely opt-in. Users who want the auto-update should re-run
catalyst auth login(new OAuth scope) and then add--update-site-url <channelId>to their deploy invocation (or setCATALYST_UPDATE_SITE_URLin CI).