CLI#
astra iris workflows does from a terminal what the console's Iris →
Workflows pages do. Every command works in the organisation and
workspace you chose with astra use
(Install the CLI), as you, so your
role in the workspace decides what it may do. astra iris workflow and
astra iris wf are the same.
Below, <workflow>, <execution> and other names in angle brackets stand
for yours.
$ astra login
$ astra use <org>/<workspace>
$ astra iris workflows apply -f card-spending.yaml
$ astra iris workflows run card-spending --event '{"id": "t1", "text": "COMPRA APROVADA R$ 250,00 PADARIA SAO JOAO"}' --wait
$ astra iris workflows triggers card-spending
$ astra iris workflows executions --flow card-spending
Common flags#
| Flag | Default | Description |
|---|---|---|
--cluster <cluster> |
The cluster astra use …@<cluster> chose, else the workspace's first |
Which of the workspace's clusters to use. Accepted by every astra iris command. |
Files given with -f are YAML or JSON with metadata and spec, as in the
workflow specification. Their apiVersion and kind,
when present, must be anemoi.astralyx/v1 and Flow.
Errors are printed as astra: <message>, with exit status 1.
astra iris workflows#
| Command | Description |
|---|---|
apply -f <file> |
Create the workflow from a file, or write its next version. --no-current writes it without making it current. Runs the cluster's checks on the file first. Prints flow <name>: version <n> written, now current. |
validate -f <file> |
Check the file here, without sending it: shape, ids, the graph, each kind's fields, triggers, the names expressions use. Warnings are printed and do not fail it. --remote also sends the file to the cluster's check (the same checks). Neither checks that what the workflow names (deployments, assistants, functions, agents, workflows, drives) exists: a missing one fails its box when it runs. Works signed out without --remote. Exit status 1 with problems. |
list |
FLOW CURRENT LATEST AGE. |
run <workflow> |
Start an execution, as you. -i, --input key=value (repeatable); --version <n>; --event <json> or --event @file.json, the event as a trigger would send it (read as ${{ event… }}); --wait follows it until it ends, prints its boxes and outputs, and exits 1 unless it Succeeded. Prints execution <execution> of flow <workflow> started. |
executions |
EXECUTION FLOW VERSION STATE STEPS WHY AGE, newest first. --flow <workflow> for one workflow's. |
get <execution> |
Its state, then STEP STATE ATTEMPTS LAST MACHINE WHY OUTPUTS, its agent runs' receipts and its outputs. --json prints the whole execution. |
triggers <workflow> |
TRIGGER KIND NEXT LAST EXECUTION ERROR: when each schedule fires next (on a call for an HTTP trigger), when it last fired, the execution it started, and why it last could not. |
cancel <execution> |
Stop its boxes under way. |
retry <execution> <step> |
Give a failed box one more attempt. |
events send <execution> <name> [key=value…] |
Send the event a wait_event box waits for; the data at most 4 KiB. |
An HTTP trigger's address is made in the console or with the
API; astra has no command for it.