Skip to main content

Overview

lua workflows manages workflow definitions and runs. Definitions are pushed with lua push workflow and activated with lua workflows deploy; runs are started, watched and steered with the run verbs.
For writing workflows see Authoring. For the run model behind these verbs see Runs and events.

Usage

  • target is the workflow name (or id) for list, view, versions, deploy, activate, deactivate, start, run, env-overlay and delete; a run id for every other verb. -i <name> / -r <runId> are the equivalent options.
  • extra is the signal name for signal <runId> <name> and the step id for job-logs <runId> <stepId>.

Subcommands

Common options

Exit codes

Definitions

lua workflows list

Columns: Name, Status, Active version, Versions, Form (static / dynamic), Id.

lua workflows view <name>

Prints the workflow’s id, status, active version, schedule, output visibility (roles, users, owner bypass), env overlay keys, and a versions table (version, form, topology, graph hash, created).

lua workflows versions <name>

The versions table alone.

lua workflows deploy <name> -v <ver|latest>

Publishes a version as the active one. On an agent under versioning this is a scoped promote: a new agent version is recorded and printed as agentVersion. Without -v the newest version is deployed.

lua workflows activate <name> / deactivate <name>

Enable or pause the workflow’s schedules and triggers. activate -v <ver> is the same as deploy.

lua workflows delete <name>

Remove the file from src/workflows/ (and its entry in lua.skill.yaml) afterwards to keep the project in sync.

lua workflows env-overlay <name> [-v <ver|latest>]

Lists every env.template() key on the version, where it resolved from, and whether it is present in the agent environment. Values are never printed. Exits 1 when a key is missing.

Starting and running

lua workflows start <name>

Prints Run <runId> · <status> and, without --follow, the watch and status commands to run next. A gated start exits 6; a concurrencyPolicy: 'forbid' workflow with a run in flight prints the blocking run id and exits 1.

lua workflows run <name>

Runs the workflow locally after compiling the project - the same as lua test workflow --name <name>. No run is created on the server. Interactive runs prompt on stdin for any approval, input or signal you did not pre-answer.

Runs

lua workflows runs

Columns: Run, Status, Trigger, Created, Correlation, Tags.

lua workflows status <runId>

Prints the run’s status, workflow and version, trigger, correlation key and tags, timings, lineage, gate (with the action that clears it), failure reason and output. A run whose outputs are restricted prints restricted instead of the output.

lua workflows watch <runId>

Streams the run’s events over SSE and prints one line per event. Reconnects from the last event id when the stream drops. Stops at the terminal event (exit 0, 4 or 5) or as soon as the run waits for a person or a gate (exit 8), printing the verb that resumes it. step.throttled events are collapsed into one counter line. Press Ctrl-C to detach without affecting the run.

lua workflows logs <runId>

Fetches the run’s events once (polling form, up to 500) and prints the progress and lifecycle ones: step.progress (your ctx.log messages), *.started, *.completed, *.failed, *.skipped, run.log.

lua workflows cancel <runId>

Prints the verdict and the next action (cancel again or force available at ...).

lua workflows resume <runId> --step <id>

Refused with a hint when the step is an approval (use approve) or a signal wait (use signal). A repeated resume prints who already resumed it.

lua workflows retry-step <runId> --step <id>

Re-arms a step that failed past its retries, parked on an exception gate, or sits on a billing hold (the only way out of a billing park after topping up). 409 STEP_NOT_PARKED when the step is running, pending or already re-armed; RUN_TERMINAL when the run ended.

lua workflows approve <runId> --approval <id>

Find the approval id with lua workflows status <runId> --json (data.suspensions[].suspend.approvalId) or in the desktop card. STEP_UP_REQUIRED means the approval must be given from the desktop with a fresh login.

lua workflows signal <runId> <name>

Prints whether the signal was consumed by a step, parked until a step waits for it, or was a duplicate.

lua workflows replay <runId> --local

Re-derives the run from the compiled artifact in the current project and compares each step’s recorded output with the local derivation. A differing graph hash is reported first. Exit 4 on a divergence. Only --local is available; pass -i <name> when several compiled workflows could match.

lua workflows delete-run <runId>

Erases a terminal run - outputs, artefacts and journal. Prompts unless --yes. A live run is refused (cancel it first).

Archiving

lua workflows archive-runs --since <iso|dur> --out <dir>

Exports every terminal run in the window as an evidence bundle, verifies each download against its manifest hash, writes <runId>.zip files and an archive-index.ndjson, and skips runs already archived with a matching hash. Exit 3 when the window holds no terminal runs, 4 when any export failed or was deferred (rate-limited or still pending).

Job tier

lua workflows workspace <runId>

Shows the run’s workspace: kind and backend, repo and ref, branch and head, size used, files changed, TTL, worktree arms (branch, head, pushed, merged, conflicts) and any error.

lua workflows jobs <runId>

Lists the run’s tier: 'job' steps: Step, Status, Attempt, Size class, Pod phase, Segment, Heartbeat, Error.

lua workflows job-logs <runId> <stepId>

Prints a header (attempt, status, pod phase, size class, segment, harness, pod name, last heartbeat, error) followed by the log lines.

Push, deploy and versions

Workflows follow the same release flow as every other primitive:
  1. lua push workflow compiles the project and mints a new immutable version of each changed workflow (--name <name> for one; aliases workflows and wf). Missing env.template() keys abort the push before anything is sent. lua push all does not include workflows - push them explicitly. --auto-deploy publishes the version straight after the push.
  2. lua workflows deploy <name> -v latest activates the version. On an agent under versioning this records a scoped promote - a new agent version identical to the current one except for this workflow - and prints its number.
  3. lua version snapshots pin workflow versions alongside skills, webhooks and jobs, so lua version promote <N> rolls a workflow back with everything else. lua version create after a push captures the newest pushed workflow versions.