Skip to main content
The CLI follows a few rules that make it predictable in a script. Results go to stdout and diagnostics go to stderr. Commands that return data take --json. Exit codes are documented and mean something specific. And nothing depends on state left behind by an earlier command: the server and the credential are worked out again on every run, from flags and environment variables.

​
Credentials in automation

A script authenticates with an API token in RELIANT_TOKEN. When it is set, the CLI uses it for every command and ignores any stored login. Create one on a computer with a browser and store it as a secret in your CI system:
The token lasts 90 days. Running the command again with the same --name replaces it, which is how you rotate it, and reliant auth token revoke ci withdraws it. There is deliberately no --token flag for this. A secret on a command line ends up in shell history and process listings, and daemon start --token already means “read a daemon credential from stdin”. Sign in and tokens compares the credential types. To target a server other than Reliant’s hosted service, set RELIANT_SERVER_URL (or pass --server). The token must have been created on that same server. Forge commands in CI use their own variable, the one each environment declares (usually FORGE_CONTROL_PLANE_TOKEN), set to an organization automation token. See Forge through Reliant.

​
Validate and test workflows on every pull request

Workflow validation and scenario tests need no credential and no network, so they can run on every pull request with nothing but the reliant binary. Both exit 1 on failure and take --json:
.github/workflows/reliant-workflows.yml
Workflows from the terminal shows what each command checks and what its failures look like.

​
JSON output

These commands take --json and print a single JSON document on stdout: For example:
reliant workflow follow (and run --follow) streams instead: one JSON event per line, for each node and workflow state change, with every diagnostic on stderr. Pipe it straight into jq or a log shipper.

​
Exit codes

0 means success everywhere, and 1 means the command itself failed. The supervision commands use more codes, so a script can tell a run that failed from a command that failed: “Completed” is not the same as “passed”. A run that reaches a terminal node declaring outcome: failure finished its graph cleanly, but the work did not pass. Every command in this table treats it as a failure, 1 (or 2 for status), so a script that checks the exit code never mistakes it for success.

​
Reacting to events with hooks

follow, watch and run --follow can run a shell command when an event happens, so a script can react without parsing the stream itself:
The event is one of node_started, node_completed, node_failed, workflow_completed, workflow_failed, question, approval or any. The hook gets the event’s JSON on stdin and RELIANT_EVENT_* environment variables (RELIANT_EVENT, RELIANT_EVENT_EXECUTION_ID, RELIANT_EVENT_NODE_ID, RELIANT_EVENT_STATE, …). A failing hook is logged and never stops the stream.