Skip to main content

v2.32.0

Release notes for orun v2.32.0.

Highlights​

  • Workflow actions — a third execution vocabulary. A plan step or a blueprint hook can now be a workflow: — a portable, provider-backed, connection-authenticated, expression-driven workflow, executed by the torkflow runtime. It sits beside run: (shell) and use: (GitHub Actions) and expresses the one thing those can't: call an authenticated system, take its structured result, pass it to the next action, and branch on it — without a curl | jq pipeline with secrets smeared through it. See Workflow actions.

  • One backend, two surfaces. The same execution backend and secret bridge serve both:

    • a workflow: plan step inside a composition job (runs during orun run, under local / docker / github-actions alike — unlike use:, no runner is forced); and
    • a workflow: blueprint hook in hooks.postInstantiate or a per-phase phases[].hooks (runs during orun new --run-hooks, after the gated tree is written).

  • A workflow is execution, never intent. The plan and the provenance lock capture only a workflow's reference + content digest + declared inputs — never its runtime outcome. plan.json folds { workflow, workflowDigest, with } into its checksum, so identical inputs still produce a byte-identical plan; the run is sealed into .orun/, and side effects (a PR URL, a message timestamp) are logged run facts, never plan or lock content. The pinned digest is re-verified before a workflow runs — a workflow that changed since the plan is a hard, fail-closed error.

  • Secrets from orun-secrets, never a second store. Credentials are the job's (or blueprint's) already-resolved secret values, injected into the engine in-memory and redacted from everything orun persists or prints. No secrets.yaml is consulted for an in-plan workflow.

  • orun workflow authoring subcommand. Validate, digest, run, or view a workflow file standalone before wiring it in. See orun workflow.

New: run a data-flow workflow as a step​

steps:
  - name: notify-oncall
    workflow: workflows/notify-oncall.yaml
    with:
      channel: "{{ .env.SLACK_CHANNEL }}"
      component: "{{ .component }}"
    timeout: 5m
    retry: 1

New: open a PR after a scaffold​

hooks:
  postInstantiate:
    - id: open-pr
      workflow: workflows/open-pr.yaml
      with: { branch: "scaffold/{{ .serviceName }}" }

New: author standalone​

orun workflow validate workflows/notify-oncall.yaml
orun workflow digest   workflows/notify-oncall.yaml
export ORUN_TORKFLOW_ENGINE=/usr/local/bin/torkflow
orun workflow run workflows/notify-oncall.yaml --set channel=ops

Compatibility​

  • Additive only. The workflow/with fields on plan steps and blueprint hooks use omitempty; existing plans, compositions, and blueprints are byte-unchanged, and their checksums are unaffected. A step or hook must set exactly one of run / use / workflow — a plan or blueprint that sets more than one now fails to compile (previously undefined).
  • Engine is opt-in. A plan or scaffold that uses no workflow: never touches the engine. One that does needs ORUN_TORKFLOW_ENGINE set (see Environment variables); a missing engine is a clear pre-flight error.
  • Ecosystem-neutral core. Provider actions (slack.*, github.*, …) live in torkflow's action store; orun names no provider, enforced by a build-time lint.
  • No existing command, schema, or route changed.