What is the location of your example repository?
https://github.com/Shopify/hydrogen/tree/main/templates/skeleton
Which package or tool is having this issue?
CLI
What version of that package or tool are you using?
@shopify/cli-hydrogen@11.1.16 & @shopify/cli@4.0.0
What version of React Router 7 are you using?
7.14.0
Steps to Reproduce
-
In Oxygen Admin, create a long-lived environment, e.g. staging with branch tag staging, exposed at a stable URL (e.g. https://staging-skeleton.hydrogen.shop/).
-
Locally, check out a different branch (e.g. a weekly release branch release/1.2.3):
git checkout release/1.2.3
-
Try to deploy that working tree to the staging environment:
shopify hydrogen deploy --env staging --env-branch release/1.2.3
The CLI rejects this:
--env-branch=release/1.2.3 cannot also be provided when using --env
-
Drop --env-branch and use only --env:
shopify hydrogen deploy --env staging
The deploy is forced to the environment's configured branch (staging); there is no way to deploy the release/1.2.3 working tree under the staging environment while preserving traceability of the source branch.
-
Drop --env and use only the deprecated flag:
shopify hydrogen deploy --env-branch staging
This flag is deprecated, and in CI (CI=1) it is also the only option, since --env is rejected with Can't specify an environment handle in CI.
Expected Behavior
Concretely, any of the following would resolve the gap:
- Allow
--env and --env-branch to be combined. --env selects the environment record (URL, secrets, env vars); --env-branch overrides the deployment tag. Both should work in interactive and CI modes.
- Replace the deprecated
--env-branch with a clearly-named successor (e.g. --deployment-tag) that composes with --env.
- Allow
--env alone to deploy the working tree against the chosen environment, without coupling the deployment tag to the environment's configured branch.
This would unblock release-train workflows where a team:
- cuts a
release/X.Y.Z branch on a regular cadence,
- needs to QA each release at a fixed staging URL backed by stable secrets/env vars,
- and wants the deployment tag in Oxygen Admin to reflect the actual source branch (
release/1.2.3), not a generic placeholder.
The same flag combination must work in CI, since releases are typically deployed from automation rather than a developer's laptop.
Actual Behavior
There is no flag combination that lets a developer deploy an arbitrary local branch to a chosen environment handle:
--env <handle> --env-branch <tag> → rejected by exclusive: ['env-branch'] in packages/cli/src/lib/flags.ts.
--env <handle> alone → the deployment tag is taken from the environment's configured branch in Admin, ignoring the local checkout. There is no opt-out.
--env-branch <tag> alone → works, but the flag is deprecated (--env-branch is deprecated. Use --env instead.) and is the only option allowed in CI today.
The result is a forced choice between (a) reconfiguring the staging environment's branch in Oxygen Admin for every release, (b) renaming branches to match a fixed tag and losing release identity, or (c) relying on a deprecated flag with no announced successor that covers this case.
What is the location of your example repository?
https://github.com/Shopify/hydrogen/tree/main/templates/skeleton
Which package or tool is having this issue?
CLI
What version of that package or tool are you using?
@shopify/cli-hydrogen@11.1.16 & @shopify/cli@4.0.0
What version of React Router 7 are you using?
7.14.0
Steps to Reproduce
In Oxygen Admin, create a long-lived environment, e.g.
stagingwith branch tagstaging, exposed at a stable URL (e.g.https://staging-skeleton.hydrogen.shop/).Locally, check out a different branch (e.g. a weekly release branch
release/1.2.3):Try to deploy that working tree to the
stagingenvironment:The CLI rejects this:
Drop
--env-branchand use only--env:The deploy is forced to the environment's configured branch (
staging); there is no way to deploy therelease/1.2.3working tree under thestagingenvironment while preserving traceability of the source branch.Drop
--envand use only the deprecated flag:This flag is deprecated, and in CI (
CI=1) it is also the only option, since--envis rejected withCan't specify an environment handle in CI.Expected Behavior
Concretely, any of the following would resolve the gap:
--envand--env-branchto be combined.--envselects the environment record (URL, secrets, env vars);--env-branchoverrides the deployment tag. Both should work in interactive and CI modes.--env-branchwith a clearly-named successor (e.g.--deployment-tag) that composes with--env.--envalone to deploy the working tree against the chosen environment, without coupling the deployment tag to the environment's configured branch.This would unblock release-train workflows where a team:
release/X.Y.Zbranch on a regular cadence,release/1.2.3), not a generic placeholder.The same flag combination must work in CI, since releases are typically deployed from automation rather than a developer's laptop.
Actual Behavior
There is no flag combination that lets a developer deploy an arbitrary local branch to a chosen environment handle:
--env <handle> --env-branch <tag>→ rejected byexclusive: ['env-branch']inpackages/cli/src/lib/flags.ts.--env <handle>alone → the deployment tag is taken from the environment's configured branch in Admin, ignoring the local checkout. There is no opt-out.--env-branch <tag>alone → works, but the flag is deprecated (--env-branch is deprecated. Use --env instead.) and is the only option allowed in CI today.The result is a forced choice between (a) reconfiguring the staging environment's branch in Oxygen Admin for every release, (b) renaming branches to match a fixed tag and losing release identity, or (c) relying on a deprecated flag with no announced successor that covers this case.