Skip to main content
Template expressions let you insert dynamic values into pipeline config. Wrap a dot-path expression in << ... >> inside any templateable field value:
Expressions can reference values from the context namespaces below and use functions such as slugify() to transform them.

​
Syntax

​
Block expressions

When the entire value is a single << ... >> expression, the resolved value keeps its original type. This is how you pass numbers, booleans, objects, and arrays through templates:

​
String interpolation

Mix one or more expressions with literal text. Each expression is evaluated, converted to a string, and concatenated. The result is always a string:

​
Slugify

Use slugify(string) to turn a URL or name into lowercase ASCII letters, digits, and hyphens. It strips a leading URL scheme such as https://, replaces runs of other characters with one hyphen, and trims leading and trailing hyphens. The hostname stays in the result.
With pipeline.input.repo set to https://github.com/ravionhq/modules, this produces terraform-github-com-ravionhq-modules. slugify() takes one string. It does not truncate the result or guarantee uniqueness: names that differ only in punctuation can produce the same slug. An input with no ASCII letters or digits produces an empty string. Disk cache keys must still be nonempty and at most 64 characters, including any prefix.

​
Literal <<

To write << as plain text, escape it with a backslash. An escaped block is kept as text and is never evaluated:
A backslash that should itself stay literal is doubled: \\<< pipeline.input.x >> is a live template preceded by one backslash. A value whose only << blocks are escaped is not a template and keeps its declared type.

​
Context namespaces

​
pipeline.input

References the values of inputs declared in the pipeline’s inputs list. Input values come from, in order of precedence: hard-coded variant input values, values passed when the run is triggered, then the input’s default.

​
pipeline.run and pipeline.variant

Run metadata and the variant the run was started with: Variants plus templating are how one pipeline serves multiple environments: name your variant IDs after your environment given IDs, then reference modules as << pipeline.variant.id >>.web-app. See Pipeline variants.

​
steps

References the outputs and inputs of other steps. The step ID must exist in the pipeline — referencing an unknown step fails validation — and expressions resolve in DAG dependency order, so a step referencing steps.build_web_app.output.* runs after build_web_app completes.
Available outputs depend on the step type. For example, build steps output build_ref, image_uri, image_digest, and status, while deploy steps output deployment_id, status, and success. CI steps additionally output exit_code, success, and duration_ms. custom steps can also publish their own outputs: declare names in the step’s outputs list and have commands append name=value lines to the file at $RAVION_OUTPUT. Each declared name is then readable as << steps.{id}.output.{name} >>.

​
Module outputs

References the stack outputs of a module instance, as of its last successful apply. Use givenId values for the project, environment, and module segments. The environment is required — a bare modules.{module}.output.* address is rejected in pipeline config because a pipeline is not tied to a single environment:
All module-output references are resolved once, before the first step starts. If a referenced module has never been applied, or the output key does not exist, the run fails during planning. Outputs a module declares as sensitive cannot be referenced; use a handle such as an ARN or secret name instead. These references do not order the pipeline after the module and do not appear as dependencies on the canvas — for module-to-module references, see output references.

​
trigger.payload

Only available inside a trigger’s run block, to map event data into pipeline inputs:

​
Templateable fields

Not every field accepts templates. Templateable fields are marked in the pipeline configuration reference. Highlights:
  • Common step fields: timeout, if
  • Module steps: module_instance, description, input
  • CI build steps: source, builder and its nested fields (dockerfile, context, build_cmd, …), environment_variables, debug
Fields that identify structure — like step id, name, and type — are not templateable.

​
Conditional steps with if

The if field accepts a boolean literal or a full block expression that resolves to a boolean:

​
Type rules

After resolution, the value must match the field’s declared type: A mismatch — for example, a timeout expression resolving to a string — fails with a template_type_mismatch error.