-
Notifications
You must be signed in to change notification settings - Fork 57
Description
Background
The CLI currently selects a plan in two ways:
--plan Essential— you pass the tier name andplan.tschecks it against the keys returned byapi.listSubscriptions()(Record<planName, slotCount>).- Interactively — if you have multiple tiers available, the CLI prompts you to pick one.
This works fine when a user has one subscription per tier. But a user with multiple subscriptions of the same tier (e.g. two "Essential" plans) has no way to target a specific one. The backend already tracks subscription instances: api.listSubscriptionsDeploys() returns SubscriptionDeploy[] where each entry has:
interface SubscriptionDeploy {
id: string;
plan: Plans;
date: number;
deploy: string;
}
// id === the SHA-like instance ID e.g. "a3f9c2d1..."
// plan === tier: "Essential" | "Standard" | "Premium"
// deploy === deployment suffix using this subscriptionThe id field is the subscription instance ID — that's what --plan-id should target.
What's needed
A --planId flag so a CI pipeline or power user can pin a deploy to an exact subscription instance:
metacall-deploy --planId a3f9c2d1... --workdir ./my-projectWhat has to change
CLI side (src/):
-
Add
planId?: stringtoCLIArgsinsrc/cli/args.ts.- Note: the TODO listed
-das the alias but-dis already taken by--dev. A new alias (e.g.--planIdwith no short alias, or-Sfor subscription) needs to be agreed on.
- Note: the TODO listed
-
In
src/plan.ts, after fetchingavailPlans, check forargs['planId']and validate it exists inlistSubscriptionsDeploys()before using it. -
In
src/deploy.ts,api.deploy()today receives aPlanstier string:api.deploy(name, env, plan: Plans, resourceType, release, version)
It would need a new optional
planIdparameter threaded through to thePOST /api/deploy/createbody. -
src/force.tsalready readsrepoSubscriptionDetails[0].planto recover the tier on re-deploy. With this change it should also propagaterepoSubscriptionDetails[0].idwhen available.
Backend side (/api/deploy/create):
The deploy endpoint currently accepts plan (tier name). It needs to optionally accept planId (subscription instance ID) and use it to pick the right subscription slot when provided.
This is the blocking part — the CLI work can be prepared, but the feature isn't useful until the backend supports it.
Why it matters
- Users with multiple active subscriptions of the same tier can't automate targeted deploys today.
- CI pipelines can't hard-pin a specific subscription instance across runs.
Alias conflict to resolve
The original TODO says (-d, --plan-id) but -d is already owned by --dev. This needs to be decided before implementation starts.
Next Steps
- Maintainer review needed on alias decision (
--planIdvs-Svs alternative) - Backend support for
planIdparameter in/api/deploy/create - CLI implementation (args parsing, validation, threading through deploy)
- Update
src/force.tsto propagate subscription instance ID on re-deploy
Willing to Implement
I'm ready to contribute! I can handle:
- CLI-side changes (
src/cli/args.ts,src/plan.ts,src/deploy.ts,src/force.ts) - Backend endpoint updates
- Tests and documentation
Blocking: Awaiting maintainer feedback on the alias conflict before starting.