feat(cli): add channel update command to update channel site url#3001
feat(cli): add channel update command to update channel site url#3001jorgemoya wants to merge 5 commits into
channel update command to update channel site url#3001Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
jorgemoya
changed the title
Bundle Size ReportComparing against baseline from
Per-Route First Load JS
|
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.
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
|
Add `--update-site-url <channelId>` (env: CATALYST_UPDATE_SITE_URL) to `catalyst deploy`. After a successful deployment the CLI PUTs the resulting deployment URL to the BC channel site endpoint (v3/channels/:channelId/site). Failures are soft: the deploy itself still succeeds and the user is told to update manually or re-run `catalyst auth login` to refresh the access token with the new `store_channel_settings` scope (added to DEVICE_OAUTH_SCOPES). Rebased onto the current alpha branch; the 5 original PR commits were squashed into one because origin/alpha was force-rewritten after the PR opened (every shared commit had a new SHA), making a per-commit replay infeasible. Refs LTRAC-446 Co-Authored-By: Claude <noreply@anthropic.com>
jorgemoya
force-pushed
the
jorgemoya/ltrac-446-cli-auto-update-bc-channel-site-url-on-deploy
branch
from
fa310a9 to
e49f807
Compare
Add a new `catalyst channel update-site-url` subcommand that PUTs a channel's site URL to one of the linked project's deployment hostnames. The flow is interactive by default — pick channel, pick hostname — and accepts `--channel-id` / `--hostname` for scripted use. When no project is linked or passed, it falls back to `selectOrCreateInfrastructureProject` (same picker the deploy command uses) so the user can resolve it inline. Replace the previous `--update-site-url <channelId>` value-bearing option on `catalyst deploy` with a boolean flag that triggers the same shared flow after a successful deploy, defaulting the hostname prompt to the freshly-deployed hostname returned by the deployment SSE. The shared `runChannelSiteUrlFlow` helper lives in lib/channel-site-flow.ts so both commands hit identical code paths; the standalone command hard-fails on errors while the deploy wrapper soft-fails (deploy already succeeded, bundle is live). Refs LTRAC-446 Co-Authored-By: Claude <noreply@anthropic.com>
Add coverage for the shared interactive flow and the two surfaces it backs: - lib/channel-site-flow.spec.ts: happy path (channel prompt + hostname prompt + PUT), --channel-id and --hostname short-circuits, both overrides skip all prompts, preferHostname appears first in the hostname options, empty channels throws, project with no hostnames throws, fallback to selectOrCreateInfrastructureProject when no projectUuid is provided, NoLinkedProjectError when no projects exist and user declines to create one, and a warn-and-reprompt path when the linked project no longer exists. - commands/channel.spec.ts: end-to-end via `program.parseAsync` — happy path, projectUuid resolved from .bigcommerce/project.json, --channel-id + --hostname skip all prompts, no-projects exit path via consola.info hint, error propagation from the PUT. - commands/deploy.spec.ts: replace the old `--update-site-url <id>` tests with the new boolean-flag flow: triggers interactive prompts after deploy, places the freshly-deployed hostname first in the hostname prompt, no API call when the flag is omitted, soft-fail with re-auth hint on 401. - tests/mocks/handlers.ts: add a default `GET /v3/channels` handler returning two storefronts so tests don't have to override the channel list shape per case. Refs LTRAC-446 Co-Authored-By: Claude <noreply@anthropic.com>
Only Catalyst-platform channels can meaningfully be pointed at a Catalyst deployment hostname, so filter the channel picker in runChannelSiteUrlFlow to drop Stencil / non-Catalyst storefronts. When the resulting list is empty, surface "No Catalyst channels found" with a hint to run `catalyst create`. Refs LTRAC-446 Co-Authored-By: Claude <noreply@anthropic.com>
…date` The subcommand is shorter and reads more naturally as a verb on the `channel` namespace. The deploy-side flag (`--update-site-url`) keeps its descriptive name since flag context is less obvious at a glance. Refs LTRAC-446 Co-Authored-By: Claude <noreply@anthropic.com>
jorgemoya
changed the title
channel update command to update channel site url
2 participants
Jira: LTRAC-446
What/Why?
Adds a new top-level subcommand,
catalyst channel update, and a boolean--update-site-urlflag oncatalyst deploythat both run the same interactive flow:selectOrCreateInfrastructureProjectif none is linked or the linked UUID no longer exists).platform === 'catalyst', and prompt the user to pick one.deployment_hostnames— prompt the user to pick one (when invoked fromdeploy --update-site-url, the just-deployed hostname is placed first as the default).This is a more discoverable replacement for the previous design (which exposed
--update-site-url <channelId>only on deploy and required the caller to already know the channel id). Standalone, the new command lets merchants point any Catalyst channel at any of the project's deployment hostnames — useful for switching channel→deployment mappings, recovering after a manual control-panel change, or wiring up a channel for the first time without re-deploying.A few decisions worth flagging for review:
--channel-id/--hostnameoverrides so it can be scripted. The deploy flag stays minimal (boolean only) because the just-deployed hostname is the obvious default.lib/channel-site-flow.tsso both surfaces hit identical code paths. The deploy wrapper soft-fails on errors (bundle is already live, non-zero exit would mislead); the standalone command hard-fails so problems are loud.platform === 'catalyst'— Stencil and other non-Catalyst storefronts can't meaningfully be pointed at a Catalyst deployment hostname, so they're omitted. Empty list surfaces "No Catalyst channels found on this store. Create one withcatalyst createand try again."store_channel_settingswas added toDEVICE_OAUTH_SCOPESin the earlier commit on this branch. Existing logged-in users need to re-runcatalyst auth loginto mint a token that includes it; the 401/403 path surfaces a re-auth hint instead of a generic error.Testing
Unit tests:
pnpm --filter @bigcommerce/catalyst test— 265/265 passing (11 inchannel-site-flow.spec.ts, 6 inchannel.spec.ts, plus updates to the existingdeploy.spec.ts--update-site-urlblock).pnpm --filter @bigcommerce/catalyst typecheckandpnpm --filter @bigcommerce/catalyst lintclean.Manual end-to-end (real store + at least one Catalyst channel + a project with at least one deployment):
catalyst auth login— confirm the new scope is requested.catalyst channel update— confirm the channel picker shows only Catalyst-platform storefronts and the hostname picker shows the linked project'sdeployment_hostnames. PUT succeeds; verify in the BC control panel.catalyst channel update --channel-id <id> --hostname <host>— confirm no prompts fire and PUT succeeds.catalyst channel updateon a store with no Catalyst channels — confirm the "No Catalyst channels found" message with thecatalyst createhint.catalyst channel updatewith no linked project — confirm it falls back toselectOrCreateInfrastructureProject. Declining a create exits cleanly with thecatalyst project createhint.catalyst deploy --update-site-url— confirm the channel prompt fires, the just-deployed hostname is the default (top of the hostname list), PUT succeeds. Verify in control panel.catalyst deploywithout the flag — confirm no channel API call is made.store_channel_settings, run the standalone command and confirm the re-auth hint surfaces.Kapture.2026-05-15.at.16.33.24.mp4
Migration
None. The flag is opt-in and the
channelcommand is new. Users who want the auto-update should re-runcatalyst auth login(new OAuth scope) before invoking either entry point.