Output Variables
Output Variables
Section titled “Output Variables”A step can pass a value to later steps by writing a service message to its output:
echo "##mantis[setVariable name='AgentUuid' value='aa-bb-cc-dd']"Later steps then reference it like any other variable:
echo "enrolling {{ AgentUuid }}"Both {{ Name }} and ${ Name } are substituted.
Declare the names an action may set
Section titled “Declare the names an action may set”An action version may only set names it declares. In config-as-code:
"1.0.0" = { version = "1.0.0", payload_type = "command", output_variables = ["AgentUuid"], payload = { type = "command", command = "bash", args = ["-c", "..."] },},An action that declares nothing can set nothing. This is what makes “a later step may overwrite an earlier value” safe: command output is not trustworthy on its own, since a script echoing untrusted data could emit a service message it never intended. Emitted names that are not declared are discarded and logged as rejected — the deployment continues, and a later step referencing that name sees the unsubstituted placeholder.
To check what a version declares, read it back from
GET /api/v1/actions/{id}/versions; each version carries its output_variables.
That is the first thing to check when a variable a step emitted never appeared
downstream.
Scoping and precedence
Section titled “Scoping and precedence”Values are scoped per target. When a step fans out across several targets, each target keeps its own value and cannot see another’s.
Output variables sit at the top of the precedence order, above the variable scope ladder, prompted answers, and deploy-time overrides. Within a deployment the most recently set value wins, so a later step’s write replaces an earlier one, and a retried step replaces the value from its failed attempt.
Sensitive values
Section titled “Sensitive values”Mark a value sensitive to keep it out of storage and displays in plaintext:
echo "##mantis[setVariable name='ApiToken' value='s3cret' sensitive='true']"A sensitive value is:
- encrypted at rest, with
********stored in its place, - shown masked in the Output Variables tab and returned masked by the REST API,
- redacted from the retained step output, so it does not survive in the deployment logs the marker was written to,
- still delivered in full to later steps that reference it.
There is no way to read the plaintext back through the UI or the public API. Treat a sensitive output variable as write-once for consumption by subsequent steps.
Limitations
Section titled “Limitations”A step with no target cannot set output variables. Values are scoped to the target that produced them, and an off-target step has no target to scope to, so its emissions are rejected with a warning.
Values are not retracted on rollback. Rolling a deployment back leaves the values its steps set in place, as a record of what ran.
Where to see them
Section titled “Where to see them”The deployment detail page has an Output variables tab listing each value with its
target and the time it was set. The same data is available at
GET /api/v1/deployments/{id}/output-variables.
