feat(template): upgrade a deployed template instance, and roll it back one step
What
insta template upgrade <service> moves a service deployed from a template to the version the
registry serves now, and insta template rollback <service> returns it one step.
Both address a service name rather than a deployment id, because that is what a person and an
agent already have in hand. The CLI resolves the deployment from the service.
Paired with insta-platform #645 and insta-console #601.
The agent-facing command reference this repository requires as a mirror is updated in
InsForge/instacloud-skills#170, which documents both commands and every flag added here.
It lives in the superproject's skills submodule, so it cannot be a file in this PR.
How
upgrade prints the plan before it does anything: the version move, and per field the live value
against the new one. A field changed by hand after deploying is marked so, because the upgrade will
overwrite it. Then it asks, and --yes or no TTY skips the question.
The plan the user saw is the plan that runs. The CLI sends back the version and digest from it, so
a republish in between answers 409 and nothing happens, with a sentence telling the user to look
again.
--set NAME=value supplies a required variable the new version adds. Variables the instance
already holds are never asked for again, and generated secrets are recovered by the platform rather
than transiting the CLI.
rollback prints its warnings before the confirmation: what the older version restores, that a
setting it does not declare keeps its current value, that a public access change on a storage
service reaches that bucket on every branch, and that data the app migrated under the newer version
is not restored. It takes --set too, because an upgrade can drop a variable the older version
still requires.
Coded 409s reach the user as sentences rather than a bare conflict. Two of them name the deployment
or the version to act on, and those keep the platform's own wording instead of being replaced with
ours, which is what KEEP_PLATFORM_SENTENCE is for.
Verify
npm run typecheckandnpm test, 103 files and 2141 tests- the plan printer, the version pin, the
--setpaths, the destroy-without-asking rule off a TTY
and each coded 409 all have cases - the no-step-back case covers both of its causes, never upgraded and already rolled back, and
asserts the platform sentence survives for each
🤖 Generated with Claude Code
Summary by cubic
Adds insta template upgrade <service> and insta template rollback <service> so a deployed template service can move to the version the registry serves now, or one step back. Both commands take a service name rather than a deployment id, show what will change before running, and confirm before acting.
upgradeprints the plan — the version move and, per field, the live value versus the new one, with hand-changed fields marked as being overwritten — then sends back the version and digest it showed, so a republish in between answers 409 and nothing runs.- An added service is shown as created by the upgrade with its field rows printed as
(none) → <new value>plus its required variables; a dropped one is left running. A skipped service now reads[skipped: …]instead of[pending]in deployment output and no longer counts against the healthy total. --set NAME=valuesupplies a required variable the new version adds; variables the instance already holds are never re-asked, and generated secrets are recovered by the platform. A rejected--setnever echoes the value, which is where a credential sits.rollbackprints its warnings before confirmation: what the older version restores, that undeclared settings keep their current value, that a public-access change on a storage service reaches that bucket on every branch, and that app-migrated data is not restored. It takes--settoo, and off a TTY it fails without--yes.- Coded 409s are raised as sentences instead of a bare conflict; two keep the platform's wording because it names the deployment or version to act on.