Workflow template context

The below keys are available in template strings for Workflow configurations, as well as the commands defined in Custom Commands.

Note that the {steps.*} key is only available for the steps[].command and steps[].script fields in Workflow configs, and may only reference previous steps in the same workflow. See below for more details.

${local.*}

Context variables that are specific to the currently running environment/machine.

${local.artifactsPath}

The absolute path to the directory where exported artifacts from test and task runs are stored.

Example:

my-variable: ${local.artifactsPath}

${local.env.*}

A map of all local environment variables (see https://nodejs.org/api/process.html#process_process_env).

${local.env.<env-var-name>}

The environment variable value.

${local.arch}

A string indicating the architecture that the framework is running on (see https://nodejs.org/api/process.html#process_process_arch)

Example:

my-variable: ${local.arch}

${local.platform}

A string indicating the platform that the framework is running on (see https://nodejs.org/api/process.html#process_process_platform)

Example:

my-variable: ${local.platform}

${local.projectPath}

The absolute path to the project root directory.

Example:

my-variable: ${local.projectPath}

${local.username}

The current username (as resolved by https://github.com/sindresorhus/username).

Example:

my-variable: ${local.username}

${local.usernameLowerCase}

The current username (as resolved by https://github.com/sindresorhus/username), with any upper case characters converted to lower case.

Example:

my-variable: ${local.usernameLowerCase}

${command.*}

Information about the currently running command and its arguments.

${command.name}

The currently running Garden CLI command, without positional arguments or option flags. This can be handy to e.g. change some variables based on whether you're running garden test or some other specific command.

Note that this will currently always resolve to "workflow" when running Workflows, as opposed to individual workflow step commands. This may be revisited at a later time, but currently all configuration is resolved once for all workflow steps.

Example:

my-variable: ${command.name}

${command.params.*}

A map of all parameters set when calling the current command. This includes both positional arguments and option flags, and includes any default values set by the framework or specific command. This can be powerful if used right, but do take care since different parameters are only available in certain commands, some have array values etc.

Option values can be referenced by the option's default name (e.g. local-mode) or its alias (e.g. local) if one is defined for that option.

${command.params.<name>}

${datetime.*}

Information about the date/time at template resolution time.

${datetime.now}

The current UTC date and time, at time of template resolution, in ISO-8601 format.

Example:

my-variable: ${datetime.now}

${datetime.today}

The current UTC date, at time of template resolution, in ISO-8601 format.

Example:

my-variable: ${datetime.today}

${datetime.timestamp}

The current UTC Unix timestamp (in seconds), at time of template resolution.

Example:

my-variable: ${datetime.timestamp}

${project.*}

Information about the Garden project.

${project.name}

The name of the Garden project.

Example:

my-variable: ${project.name}

${git.*}

Information about the current state of the project's Git repository.

${git.branch}

The current Git branch, if available. Resolves to an empty string if HEAD is in a detached state (e.g. when rebasing), or if the repository has no commits.

When using remote sources, the branch used is that of the project/top-level repository (the one that contains the project configuration).

The branch is resolved at the start of the Garden command's execution, and is not updated if the current branch changes during the command's execution (which could happen, for example, when using watch-mode commands).

Example:

my-variable: ${git.branch}

${git.commitHash}

The current Git commit hash, if available. Resolves to an empty string if the repository has no commits.

When using remote sources, the hash used is that of the project/top-level repository (the one that contains the project configuration).

The hash is resolved at the start of the Garden command's execution, and is not updated if the current commit changes during the command's execution (which could happen, for example, when using watch-mode commands).

Example:

my-variable: ${git.commitHash}

${git.originUrl}

The remote origin URL of the project Git repository.

When using remote sources, the URL is that of the project/top-level repository (the one that contains the project configuration).

Example:

my-variable: ${git.originUrl}

${secrets.<secret-name>}

The secret's value.

${variables.*}

A map of all variables defined in the project configuration, including environment-specific variables.

${variables.<variable-name>}

${var.*}

Alias for the variables field.

${var.<name>}

Number, string or boolean

${environment.*}

Information about the environment that Garden is running against.

${environment.name}

The name of the environment Garden is running against, excluding the namespace.

Example:

my-variable: ${environment.name}

${environment.fullName}

The full name of the environment Garden is running against, including the namespace.

Example:

my-variable: ${environment.fullName}

${environment.namespace}

The currently active namespace (if any).

Example:

my-variable: ${environment.namespace}

${inputs.*}

The inputs provided to the config through a template, if applicable.

${inputs.<input-key>}

${parent.*}

Information about the config parent, if any (usually a template, if applicable).

${parent.name}

The name of the parent config.

${template.*}

Information about the template used when generating the config, if applicable.

${template.name}

The name of the template.

${steps.*}

Reference previous steps in a workflow. Only available in the steps[].command and steps[].script fields. The name of the step should be the explicitly set name of the other step, or if one is not set, use step-<n>, where is the sequential number of the step (starting from 1).

${steps.<step-name>.log}

The full output log from the step.

${steps.<step-name>.outputs.*}

The outputs returned by the step, as a mapping. Script steps will always have stdout and stderr keys. Command steps return different keys, including potentially nested maps and arrays. Please refer to each command for its output schema.

${steps.<step-name>.outputs.<output-key>}

Last updated