Output Variables

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}"

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

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

Mark a value sensitive to keep it encrypted at rest and out of displays:

echo "##mantis[setVariable name='ApiToken' value='s3cret' sensitive='true']"

A sensitive value is:

• encrypted at rest, with ******** stored in the readable column,
• 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.

How a later step receives it

The value is not written into the queued command that references it. The command is stored with the variable’s placeholder still in place and the value sealed beside it, under a key bound to that command; the substitution is completed as the command is handed to the agent over its authenticated connection. A sensitive output variable is therefore encrypted in every row that holds it, and exists in plaintext only in flight and in the process that runs the step.

A command carrying a sealed value is delivered by polling rather than published to the message bus, so the plaintext never reaches the broker. This is the same treatment a sensitive variable from the variable scope ladder gets — both travel sealed and are opened only at delivery.

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.

A value over 64 KiB is rejected. It is discarded the same way an undeclared name is, with a warning in the deployment log and no value stored.

Names are up to 255 characters of A-Z, a-z, 0-9 and _, starting with a letter or _. The name becomes a MANTIS_<NAME> environment variable for later steps and must lex inside a #{Name} template reference, so a leading digit is out along with anything outside that set. A name that breaks this rule is rejected when the action is saved, not at run time.

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.