# The schema version of this workflow's config (currently not used).
apiVersion: garden.io/v0
​
kind: Workflow
​
# The name of this workflow.
name:
​
# A description of the workflow.
description:
​
# A map of environment variables to use for the workflow. These will be available to all steps in the workflow.
envVars: {}
​
# 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
# configurations.
files:
  - # 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.**
    path:
​
    # The file data as a string.
    data:
​
    # The name of a Garden secret to copy the file data from (Garden Enterprise only).
    secretName:
​
# The number of hours to keep the workflow pod running after completion.
keepAliveHours: 48
​
resources:
  requests:
    # The minimum amount of CPU the workflow needs in order to be scheduled, in millicpus (i.e. 1000 = 1 CPU).
    cpu:
​
    # The minimum amount of RAM the workflow needs in order to be scheduled, in megabytes (i.e. 1024 = 1 GB).
    memory:
​
  limits:
    # The maximum amount of CPU the workflow pod can use, in millicpus (i.e. 1000 = 1 CPU).
    cpu:
​
    # The maximum amount of RAM the workflow pod can use, in megabytes (i.e. 1024 = 1 GB).
    memory:
​
  # The maximum amount of CPU the workflow pod can use, in millicpus (i.e. 1000 = 1 CPU).
  cpu:
​
  # The maximum amount of RAM the workflow pod can use, in megabytes (i.e. 1024 = 1 GB).
  memory:
​
# The steps the workflow should run. At least one step is required. Steps are run sequentially. If a step fails,
# subsequent steps are skipped.
steps:
  - # 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`
    # fields.
    name:
​
    # A Garden command this step should run, followed by any required or optional arguments and flags.
    # Arguments and options for the commands may be templated, including references to previous steps, but for now
    # the commands themselves (as listed below) must be hard-coded.
    #
    # Supported commands:
    #
    # `[build]`
    # `[delete, environment]`
    # `[delete, service]`
    # `[deploy]`
    # `[exec]`
    # `[get, config]`
    # `[get, outputs]`
    # `[get, status]`
    # `[get, task-result]`
    # `[get, test-result]`
    # `[link, module]`
    # `[link, source]`
    # `[publish]`
    # `[run, task]`
    # `[run, test]`
    # `[test]`
    # `[update-remote, all]`
    # `[update-remote, modules]`
    # `[update-remote, sources]`
    #
    #
    command:
​
    # A description of the workflow step.
    description:
​
    # 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
    # workflow level.
    envVars: {}
​
    # 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.
    script:
​
    # Set to true to skip this step. Use this with template conditionals to skip steps for certain environments or
    # scenarios.
    skip: false
​
    # 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
    # and examples.
    when: onSuccess
​
# A list of triggers that determine when the workflow should be run, and which environment should be used (Garden
# Enterprise only).
triggers:
  - # The environment name (from your project configuration) to use for the workflow when matched by this trigger.
    environment:
​
    # 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.
    namespace:
​
    # A list of [GitHub events](https://docs.github.com/en/developers/webhooks-and-events/webhook-events-and-payloads)
    # that should trigger this workflow.
    #
    # See the Garden Enterprise documentation on [configuring
    # workflows](https://enterprise.docs.garden.io/further-reading/workflows) for more details.
    #
    # Supported events:
    #
    # `pull-request`, `pull-request-closed`, `pull-request-merged`, `pull-request-opened`, `pull-request-reopened`,
    # `pull-request-updated`
    #
    #
    events:
​
    # 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`).
    branches:
​
    # If specified, only run the workflow for pull/merge requests whose base branch matches one of these filters.
    baseBranches:
​
    # 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`).
    ignoreBranches:
​
    # If specified, do not run the workflow for pull/merge requests whose base branch matches one of these filters.
    ignoreBaseBranches:

name: "my-workflow"

files:
  - path: ".auth/kubeconfig.yaml"

steps:
  - command:
      - run
      - task
      - my-task

steps:
  - skip: "${environment.name != 'prod'}"