opschain templates re-resolve

templates

Rolls an installed pack out across the estate in one verb. Template versions seal the pack versions they resolve, so upgrading a pack normally means cutting a new version of every template that uses it. re-resolve does that walk for you: it finds every template whose latest version resolves the named pack through an unversioned installed: declaration, cuts one new template version per template with only that pack pin moved — the same Git commit, description, properties, settings and every other pin — and reports the set.

A packs.yaml declaration that carries an explicit version: is never touched, and already-sealed versions never move: existing versions and the changes running on them are untouched.

The target version is --version when given; otherwise the pack's admin pin (opschain admin packs pin), else the highest installed semantic version. The cut version is labelled <source version>+<target version> (for example 1.0+1.1.0).

Requires administrator rights, the same as the other admin packs verbs.

opschain templates re-resolve --pack opschain-pack-infrastructure --dry-run
Dry run — nothing was cut. Re-resolving pack opschain-pack-infrastructure to version 1.2.2 would affect:
PROJECT  TEMPLATE  STATUS       FROM   TO     SOURCE VERSION  NEW VERSION  ASSETS
web      alpha     re_resolved  1.2.1  1.2.2  1.0             1.0+1.2.2    3
web      beta      pinned       1.2.0  1.2.2  2.4             -            1

opschain templates re-resolve --pack opschain-pack-infrastructure --queue-asset-upgrades
Re-resolved pack opschain-pack-infrastructure to version 1.2.2:
PROJECT  TEMPLATE  STATUS       FROM   TO     SOURCE VERSION  NEW VERSION  ASSETS
web      alpha     re_resolved  1.2.1  1.2.2  1.0             1.0+1.2.2    3 (queued)
web      beta      pinned       1.2.0  1.2.2  2.4             -            1

Statuses: re_resolved (a version was — or on a dry run would be — cut), up_to_date (the latest version already seals the target) and pinned (every declaration of the pack carries an explicit version:, so the template is untouched).

--queue-asset-upgrades additionally moves each re-resolved template's assets from the source version onto the cut version through the standard assignment flow — per-asset authorisation applies exactly as if you had reassigned them yourself; without it the cut versions sit ready for opschain templates assign.

-o, --output json|yaml emits the full report rows, asset paths included.

Flags

Flag	Meaning
--pack <name>	Installed pack whose templates to re-resolve (required).
--version <semver>	Target installed version (default: the pack's pin, else the highest installed semver).
--dry-run	Report the affected set without cutting anything.
--queue-asset-upgrades	Also move each template's assets onto the cut version through the standard assignment flow.
--server <url>	Server base URL (default: the active context / OPSCHAIN_SERVER).
--auth-token <token>	Admin bearer token override (default: your opschain login session, then $OPSCHAIN_ADMIN_TOKEN, then the token stored by opschain admin login).

See also

• opschain docs cli/admin-packs — install, list, pin and delete the installed pack versions this verb re-resolves onto.
• opschain docs cli/templates-assign — the per-template assignment flow queued upgrades ride.