Skip to main content
Version: v5.7.0

MintPress pack composition

packs:mintpress

How MintPress features compose with the rest of the stack — YAML actions, changes, asset templates and workflows. This page is only applicable to existing MintPress customers and those using the MintPress SDK or the packs:mintpress feature. Everything on this page requires the packs:mintpress licence entitlement (see entitlements): enforcement lives at the change-create funnel every MintPress-backed change passes through, so none of the syntaxes below carries a gate of its own — an unentitled create refuses with the entitlement error before anything here runs. For the shared machinery — the YAML action format, composition with uses:, workflows — start from the core pages this one links back to.

Grafting a MintPress action into a YAML action: uses: mintpress#<ref>​

A YAML action on a MintPress-backed asset template may pull one of the asset's MintPress catalog actions into its own tree:

# .opschain/actions/provision_stack.yaml
action: provision_stack
steps:
  - name: preflight
    run: ./scripts/preflight.sh
  - name: bring_up
    uses: "mintpress#Startup"
  - name: verify
    run: ./scripts/verify.sh

<ref> accepts the same three forms the catalog resolves everywhere else: the catalog full path (Binaries/jdk), the wire identity (mintmodel:jdk), or the bare action name — matched case-insensitively. (User-facing surfaces say MintPress; the stored catalog identities keep their mintmodel: spelling for upstream parity, which is why the wire identity looks different from the prefix.)

The referenced subtree is grafted into the change's tree at change creation, server-side, from the asset's stored MintPress catalog:

  • The plan shows the grafted children (per-host steps included) at create, re-rooted under your step's name.
  • Grafted steps execute exactly as invoking the catalog action directly would — the same commands, on the Ruby runner lane. There is no behavioural difference between uses: mintpress#Startup and running Startup as its own change, beyond the surrounding steps.
  • The MintPress validity gates apply unchanged: a stale or never-concretised MintModel refuses the change with the usual concretise/regenerate message before the action file even compiles.

Validation is eager and loud:

  • A reference that matches nothing in the asset's MintPress catalog is a named 422 at change creation, and the composed action lists as invalid in the asset's action catalog (naming the dangling reference) until it is fixed.
  • with: is rejected on a mintpress# step — MintPress actions are property-driven; shape them with property_overrides on the change (opschain docs getting-started/1-3-properties-and-settings).
  • The scheme only works where an asset's stored MintPress catalog exists: a project/environment (git-remote) change, a local-mode run, and a step inside a for_each expansion each refuse with a named error.

Ruby-lane steps that report children​

A bridged uses: actions.rb#<action> step or a grafted MintPress step may report child steps while it runs (MintPress actions routinely do). Those children are adopted into the tree and executed on the same Ruby lane, exactly as catalog and discovered runs treat reported children. A child report from a purely declarative step (a plain run: step) is refused as a named step failure — it is never recorded silently.

MintPress-backed assets in changes and workflows​

  • A change on a MintPress-only asset (one whose catalog comes entirely from the MintModel render, with no actions.rb export) creates and runs from the stored MintPress catalog alone.
  • A workflow type: change step may target a MintPress-backed asset with any of its catalog actions — including mintpress/mintmodel ones — through the same create funnel, so entitlement and validity gates apply to the nested change automatically. See opschain docs getting-started/4-1-anatomy-and-the-step-kinds for the step grammar.

Where the core documentation lives​

  • YAML action authoring and uses: composition: the YAML actions runbook, opschain docs getting-started/2-1-your-first-action.
  • Workflows and the change step: the workflows runbook, opschain docs getting-started/4-1-anatomy-and-the-step-kinds.
  • The packs:mintpress entitlement and its funnel enforcement: entitlements.