# The schema version of this workflow's config (currently not used).
# The name of this workflow.
# A description of the workflow.
# A map of environment variables to use for the workflow. These will be available to all steps in the workflow.
# A list of files to write before starting the workflow.
# This is useful to e.g. create files required for provider authentication, and can be created from data stored in
# secrets or templated strings.
# Note that you cannot reference provider configuration in template strings within this field, since they are resolved
# after these files are generated. This means you can reference the files specified here in your provider
- # POSIX-style path to write the file to, relative to the project root (or absolute). If the path contains one
# or more directories, they are created automatically if necessary.
# If any of those directories conflict with existing file paths, or if the file path conflicts with an existing
# directory path, an error will be thrown.
# **Any existing file with the same path will be overwritten, so be careful not to accidentally overwrite files
# unrelated to your workflow.**
# The file data as a string.
# The name of a Garden secret to copy the file data from (Garden Cloud only).
# The number of hours to keep the workflow pod running after completion.
# The minimum amount of CPU the workflow needs in order to be scheduled, in millicpus (i.e. 1000 = 1 CPU).
# The minimum amount of RAM the workflow needs in order to be scheduled, in megabytes (i.e. 1024 = 1 GB).
# The maximum amount of CPU the workflow pod can use, in millicpus (i.e. 1000 = 1 CPU).
# The maximum amount of RAM the workflow pod can use, in megabytes (i.e. 1024 = 1 GB).
# The maximum amount of CPU the workflow pod can use, in millicpus (i.e. 1000 = 1 CPU).
# The maximum amount of RAM the workflow pod can use, in megabytes (i.e. 1024 = 1 GB).
# The steps the workflow should run. At least one step is required. Steps are run sequentially. If a step fails,
# subsequent steps are skipped.
- # An identifier to assign to this step. If none is specified, this defaults to "step-<number of step>", where
# <number of step> is the sequential number of the step (first step being number 1).
# This identifier is useful when referencing command outputs in following steps. For example, if you set this
# to "my-step", following steps can reference the \${steps.my-step.outputs.*} key in the `script` or `command`
# A Garden command this step should run, followed by any required or optional arguments and flags.
# Note that commands that are _persistent_—e.g. the dev command, commands with a watch flag set, the logs command
# with following enabled etc.—are not supported. In general, workflow steps should run to completion.
# Global options like --env, --log-level etc. are currently not supported for built-in commands, since they are
# handled before the individual steps are run.
# A description of the workflow step.
# A map of environment variables to use when running script steps. Ignored for `command` steps.
# Note: Environment variables provided here take precedence over any environment variables configured at the
# A bash script to run. Note that the host running the workflow must have bash installed and on path.
# It is considered to have run successfully if it returns an exit code of 0. Any other exit code signals an error,
# and the remainder of the workflow is aborted.
# The script may include template strings, including references to previous steps.
# Set to true to skip this step. Use this with template conditionals to skip steps for certain environments or
# If used, this step will be run under the following conditions (may use template strings):
# `onSuccess` (default): This step will be run if all preceding steps succeeded or were skipped.
# `onError`: This step will be run if a preceding step failed, or if its preceding step has `when: onError`.
# If the next step has `when: onError`, it will also be run. Otherwise, all subsequent steps are ignored.
# `always`: This step will always be run, regardless of whether any preceding steps have failed.
# `never`: This step will always be ignored.
# See the [workflows guide](https://docs.garden.io/using-garden/workflows#the-skip-and-when-options) for details
# A list of triggers that determine when the workflow should be run, and which environment should be used (Garden
- # The environment name (from your project configuration) to use for the workflow when matched by this trigger.
# The namespace to use for the workflow when matched by this trigger. Follows the namespacing setting used for
# this trigger's environment, as defined in your project's environment configs.
# events](https://docs.github.com/en/developers/webhooks-and-events/webhooks/webhook-events-and-payloads) that
# should trigger this workflow.
# See the Garden Cloud documentation on [configuring
# workflows](https://cloud.docs.garden.io/getting-started/workflows) for more details.
# `pull-request`, `pull-request-closed`, `pull-request-merged`, `pull-request-opened`, `pull-request-reopened`,
# `pull-request-updated`, `push`
# If specified, only run the workflow for branches matching one of these filters. These filters refer to the
# pull/merge request's head branch (e.g. `my-feature-branch`), not the base branch that the pull/merge request
# would be merged into if approved (e.g. `main`).
# If specified, only run the workflow for pull/merge requests whose base branch matches one of these filters.
# If specified, do not run the workflow for branches matching one of these filters. These filters refer to the
# pull/merge request's head branch (e.g. `my-feature-branch`), not the base branch that the pull/merge request
# would be merged into if approved (e.g. `main`).
# If specified, do not run the workflow for pull/merge requests whose base branch matches one of these filters.