Skip to main content
Version: v5.7.0

14.1 The MintPress action pack

packs:mintpress

After this you can: use the licensed MintPress action pack — prerequisites, templates, actions as changes, composing, workflows, the runner image.

Before you start — tick each one:

  • Lesson 3.1 — Your first change (opschain learn 3.1)

In the GUI: the pack's actions appear on the Run form of a MintPress-backed asset, and the asset's MintModel tab shows the stored model and its history.

MintPress is LimePoint's commercial automation pack for enterprise middleware estates: model-driven actions rendered from a MintModel — a declarative model of the target system — and executed by the MintPress SDK. With the pack licensed, MintPress actions appear in your asset catalogs and run through exactly the same machinery as everything else you have met on the core path: changes, workflows, YAML composition, properties and the vault. This lesson is only applicable to existing MintPress customers and those using the MintPress SDK or the packs:mintpress feature.

This lesson covers only what is different when MintPress is in the picture. Every section names the lesson that owns the underlying feature — read those first; this lesson assumes them.

Licence entitlement. Everything here requires the packs:mintpress entitlement on your server's licence (apply licences as in opschain docs entitlements). Enforcement is per step at the change-create funnel every MintPress-backed change passes through: without the entitlement, invoking a Ruby-lane action (actions.rb, stored-catalog or MintModel), retrying one, rendering a MintModel and deriving an actions catalog all refuse with a named 422 — while assets on MintModel-backed templates still create, re-pin and run all their YAML actions, catalogs stay listed with entitlement_required markers, and the server's docs surfaces hide the MintPress pack pages. Nothing already running is interrupted by licence expiry mid-run.

1. What you need before starting​

  • A server whose licence carries packs:mintpress (check opschain admin status, or GET /api/info → licence_status.features).
  • A template repository containing a MintModel folder (your LimePoint engagement supplies this), reachable through a configured Git remote — remotes and templates work exactly as in opschain learn 3.3.
  • A runner built from the MintPress SDK runner image (examples/mintpress-runner-image in the distribution) — the only runner that carries the SDK and its Ruby toolchain. Plain runners from opschain learn 6.1 cannot execute MintPress work.

2. MintPress-backed asset templates​

You create templates and pin versions the normal way (opschain learn 3.4). A version whose tree carries a MintModel folder is MintModel-backed, and that adds one step to the lifecycle: before the asset can run MintPress actions, the model must be concretised — the runner renders the MintModel against the asset's converged properties and stores the result with its derived action trees.

  • Concretisation happens automatically with a catalog refresh (Generate Actions), or explicitly through the asset's mintmodels/generate link (follow the asset's links.mintmodels — never hand-build the path).
  • A stored MintModel stays valid until its inputs move: repointing the template version to a new commit, or changing a property that feeds the render, invalidates it. An invalid MintModel refuses new changes with a message naming the reason; regenerating restores it.
  • Pinning an asset onto a MintModel-backed version is itself gated: asset create/update and bulk version assignment refuse without the entitlement.

See opschain docs resources/mintmodel for the stored-model and history endpoints the GUI's MintModel tab reads.

3. Running MintPress actions as changes​

After concretisation the asset's action catalog lists the MintPress actions (Startup, Shutdown, per-component installs — whatever the model defines) beside any YAML actions. Browse and run them exactly as in opschain learn 3.1:

opschain actions list projects/acme/environments/prod/assets/oam
opschain runs create change projects/acme/environments/prod/assets/oam --action Startup --follow
created change 01a2fd00-7e8f-7a9b-8c0d-1e2f3a4b5c6d (Startup on projects/acme/environments/prod/assets/oam) — pending

Two differences from the YAML actions you authored on the core path:

  • MintPress actions are property-driven. They take no typed inputs; shape a run with property_overrides on the change, and with the properties overlay generally (opschain learn 1.3).
  • They execute on the Ruby lane. A MintPress action's steps — per-host children included — run inside the MintPress SDK runner, and the whole run is run-scoped: pinned to one runner, sharing one workspace, so files staged by one step are there for the next.

4. Composing MintPress steps into YAML actions​

A YAML action on a MintPress-backed asset can graft one of the asset's MintPress catalog actions into its own tree with the mintpress# scheme (composition with uses: is core material — opschain learn 2.2):

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

Feature-specific points, in the order they will bite:

  • <ref> resolves like everywhere else: catalog full path, wire identity (mintmodel:<name> — stored identities keep the upstream spelling), or bare action name, case-insensitively.
  • The referenced subtree is grafted server-side at change creation from the stored MintPress catalog; the plan shows the grafted children before you approve anything.
  • Validation is eager and loud: a dangling reference is a named 422 at create, and the composed action lists as invalid in the catalog until fixed. A stale MintModel refuses the change first.
  • with: is rejected on a mintpress# step — property-driven lane; use property_overrides.
  • MintPress steps routinely report child steps while running; those children are adopted and executed on the same Ruby lane.

The full scheme reference — every error message, the resolution rules, where the scheme is unavailable (git-remote changes, --local, for_each) — is opschain docs packs-mintpress.

5. MintPress in workflows​

A workflow type: change step may target a MintPress-backed asset with any of its catalog actions — the nested change goes through the same create funnel, so entitlement and MintModel-validity gates apply to it for free. Author and run workflows as in opschain learn 4.1; nothing MintPress-specific appears in the workflow grammar itself.

6. The runner image, placement and sizing​

MintPress work needs the SDK runner image, and you almost always want it fenced off as its own fleet (runner mechanics: opschain learn 6.1; groups and placement: opschain learn 6.3):

  • Create an exclusive group (say mintpress) and start the SDK image's runners into it. Exclusive is what makes the fence two-sided: SDK runners take only work that names the group, and work that names it can only land on them.

  • Route the Ruby assets to the group with a settings block on the asset (or the environment/project when a whole subtree is MintPress):

    {"runner": {"group": "mintpress"}}

    Catalog refreshes for the routed asset follow the same placement, so Generate Actions also lands on the SDK fleet.

  • The SDK runner resolves vault secrets at render and execution time: MintModel templates call the secret vault for passwords, so the fleet's runners carry the vault in the secrets_providers section of their config.yaml (a provider the estate registered with resolution: runner) — vault credentials live with the runner, never in the settings system or on the server. The vault itself, and secret-vault:// references in properties, are core material: opschain learn 3.5.

Sizing. A MintPress change is run-scoped: one runner owns the whole run. By default its steps execute serially; set runner.max_parallel_steps (same runner settings block, nearest node wins) above 1 to let the pinned runner execute that many of the run's steps concurrently in the shared workspace — this is how parallel branches of a MintPress tree (per-host fan-outs especially) regain their concurrency. Size it to what one runner host can bear, not to the fleet: a run never spreads past its one runner, so fleet width buys you concurrent changes, while max_parallel_steps buys parallelism inside each change. See opschain docs settings and opschain docs dispatch for the resolution and claim-admission detail.

Check yourself​

  • Which runner image does a MintPress action need, and what must happen to a MintModel-backed asset after its template version is pinned before its MintPress actions can run?

What you learned​

  • MintPress rides the stack you already know: templates pin a MintModel, concretisation stores the rendered model and its actions.
  • Changes and workflows run them through the ordinary funnels, where the packs:mintpress entitlement is enforced; uses: mintpress# grafts them into your YAML actions.
  • Properties and the vault shape them; a dedicated exclusive SDK runner fleet executes them — run-scoped, sized with runner.max_parallel_steps.

Deep references: opschain docs packs-mintpress (the composition scheme), opschain docs resources/mintmodel (stored models and history), opschain docs entitlements (licensing), opschain docs dispatch (placement and the run pin).

Next: this closes the module Packs — back to your track (opschain learn).