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 and its provenance. Without --version the target is the estate default — the pack's admin pin (opschain admin packs pin), else the highest installed semantic version — and every cut version's moved pin records that provenance (decided_by: admin_pin or highest_installed in its sealed_packs). With --version <semver> the named installed version is written as every cut version's explicit pin (decided_by: explicit): a later fetch of that version's revision keeps the choice instead of re-resolving it onto the estate default. The cut version is labelled <source version>+<target version> (for example 1.0+1.1.0). A latest version already sealing the target is reported up_to_date whatever its pins' provenance — to change an existing version's own pin, use opschain templates version upsert --pack on that version rather than cutting an identical one.

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 --version 1.2.3 --dry-run
Dry run — nothing was cut. Re-resolving pack opschain-pack-infrastructure to version 1.2.3 would set the explicit pin 1.2.3 on 1 template(s):
PROJECT  TEMPLATE  STATUS       FROM   TO     SOURCE VERSION  NEW VERSION  ASSETS
web      alpha     re_resolved  1.2.1  1.2.3  1.0             1.0+1.2.3    3
web      beta      pinned       1.2.0  1.2.3  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, written as every cut version's explicit pin (default: the pack's pin, else the highest installed semver, with that provenance).
--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-version-upsert — set or clear one template version's explicit pack pin (--pack <name>=<version>).
• opschain docs cli/templates-assign — the per-template assignment flow queued upgrades ride.