Config Files
Below is the schema reference for the Project, Module and Workflow garden.yml configuration files. For an introduction to configuring a Garden project, please look at our configuration guide.
The reference is divided into a few sections:
Note that individual providers, e.g. kubernetes, add their own project level configuration keys. The provider types are listed on the Providers page.
Likewise, individual module types, e.g. container, add additional configuration keys at the module level. Module types are listed on the Module Types page.
Please refer to those for more details on provider and module configuration.

Project YAML schema

The values in the schema below are the default values.
1
# Indicate what kind of config this is.
2
kind: Project
3
​
4
# The name of the project.
5
name:
6
​
7
# A list of environments to configure for the project.
8
environments:
9
- # The name of the environment.
10
name:
11
​
12
# Set the default namespace to use. This can be templated to be user-specific, or to use an environment variable
13
# (e.g. in CI).
14
#
15
# You can also set this to `null`, in order to require an explicit namespace to be set on usage. This may be
16
# advisable for shared environments, but you may also be able to achieve the desired result by templating this
17
# field, as mentioned above.
18
defaultNamespace: default
19
​
20
# Flag the environment as a production environment.
21
#
22
# Setting this flag to `true` will activate the protection on the `deploy`, `test`, `task`, `build`,
23
# and `dev` commands. A protected command will ask for a user confirmation every time is run against
24
# an environment marked as production.
25
# Run the command with the "--yes" flag to skip the check (e.g. when running Garden in CI).
26
#
27
# This flag is also passed on to every provider, and may affect how certain providers behave.
28
# For more details please check the documentation for the providers in use.
29
production: false
30
​
31
# Specify a path (relative to the project root) to a file containing variables, that we apply on top of the
32
# _environment-specific_ `variables` field.
33
#
34
# The format of the files is determined by the configured file's extension:
35
#
36
# * `.env` - Standard "dotenv" format, as defined by [dotenv](https://github.com/motdotla/dotenv#rules).
37
# * `.yaml`/`.yml` - YAML. The file must consist of a YAML document, which must be a map (dictionary). Keys may
38
# contain any value type.
39
# * `.json` - JSON. Must contain a single JSON _object_ (not an array).
40
#
41
# _NOTE: The default varfile format will change to YAML in Garden v0.13, since YAML allows for definition of
42
# nested objects and arrays._
43
#
44
# If you don't set the field and the `garden.<env-name>.env` file does not exist,
45
# we simply ignore it. If you do override the default value and the file doesn't exist, an error will be thrown.
46
varfile:
47
​
48
# A key/value map of variables that modules can reference when using this environment. These take precedence over
49
# variables defined in the top-level `variables` field, but may also reference the top-level variables in template
50
# strings.
51
variables: {}
52
​
53
# A list of providers that should be used for this project, and their configuration. Please refer to individual
54
# plugins/providers for details on how to configure them.
55
providers:
56
- # The name of the provider plugin to use.
57
name:
58
​
59
# List other providers that should be resolved before this one.
60
dependencies: []
61
​
62
# If specified, this provider will only be used in the listed environments. Note that an empty array effectively
63
# disables the provider. To use a provider in all environments, omit this field.
64
environments:
65
​
66
# The default environment to use when calling commands without the `--env` parameter. May include a namespace name, in
67
# the format `<namespace>.<environment>`. Defaults to the first configured environment, with no namespace set.
68
defaultEnvironment: ''
69
​
70
# Specify a list of filenames that should be used as ".ignore" files across the project, using the same syntax and
71
# semantics as `.gitignore` files. By default, patterns matched in `.gardenignore` files, found anywhere in the
72
# project, are ignored when scanning for modules and module sources (Note: prior to version 0.12.0, `.gitignore` files
73
# were also used by default).
74
# Note that these take precedence over the project `module.include` field, and module `include` fields, so any paths
75
# matched by the .ignore files will be ignored even if they are explicitly specified in those fields.
76
# See the [Configuration Files
77
# guide](https://docs.garden.io/using-garden/configuration-overview#including-excluding-files-and-directories) for
78
# details.
79
dotIgnoreFiles:
80
- .gardenignore
81
​
82
# Control where to scan for modules in the project.
83
modules:
84
# Specify a list of POSIX-style paths or globs that should be scanned for Garden modules.
85
#
86
# Note that you can also _exclude_ path using the `exclude` field or by placing `.gardenignore` files in your source
87
# tree, which use the same format as `.gitignore` files. See the [Configuration Files
88
# guide](https://docs.garden.io/using-garden/configuration-overview#including-excluding-files-and-directories) for
89
# details.
90
#
91
# Unlike the `exclude` field, the paths/globs specified here have _no effect_ on which files and directories Garden
92
# watches for changes. Use the `exclude` field to affect those, if you have large directories that should not be
93
# watched for changes.
94
#
95
# Also note that specifying an empty list here means _no paths_ should be included.
96
include:
97
​
98
# Specify a list of POSIX-style paths or glob patterns that should be excluded when scanning for modules.
99
#
100
# The filters here also affect which files and directories are watched for changes. So if you have a large number of
101
# directories in your project that should not be watched, you should specify them here.
102
#
103
# For example, you might want to exclude large vendor directories in your project from being scanned and watched, by
104
# setting `exclude: [node_modules/**/*, vendor/**/*]`.
105
#
106
# Note that you can also explicitly _include_ files using the `include` field. If you also specify the `include`
107
# field, the paths/patterns specified here are filtered from the files matched by `include`.
108
#
109
# The `include` field does _not_ affect which files are watched.
110
#
111
# See the [Configuration Files
112
# guide](https://docs.garden.io/using-garden/configuration-overview#including-excluding-files-and-directories) for
113
# details.
114
exclude:
115
​
116
# A list of output values that the project should export. These are exported by the `garden get outputs` command, as
117
# well as when referencing a project as a sub-project within another project.
118
#
119
# You may use any template strings to specify the values, including references to provider outputs, module
120
# outputs and runtime outputs. For a full reference, see the [Output configuration
121
# context](https://docs.garden.io/reference/template-strings#output-configuration-context) section in the Template
122
# String Reference.
123
#
124
# Note that if any runtime outputs are referenced, the referenced services and tasks will be deployed and run if
125
# necessary when resolving the outputs.
126
outputs:
127
- # The name of the output value.
128
name:
129
​
130
# The value for the output. Must be a primitive (string, number, boolean or null). May also be any valid template
131
# string.
132
value:
133
​
134
# A list of remote sources to import into project.
135
sources:
136
- # The name of the source to import
137
name:
138
​
139
# A remote repository URL. Currently only supports git servers. Must contain a hash suffix pointing to a specific
140
# branch or tag, with the format: <git remote url>#<branch|tag>
141
repositoryUrl:
142
​
143
# Specify a path (relative to the project root) to a file containing variables, that we apply on top of the
144
# project-wide `variables` field.
145
#
146
# The format of the files is determined by the configured file's extension:
147
#
148
# * `.env` - Standard "dotenv" format, as defined by [dotenv](https://github.com/motdotla/dotenv#rules).
149
# * `.yaml`/`.yml` - YAML. The file must consist of a YAML document, which must be a map (dictionary). Keys may
150
# contain any value type.
151
# * `.json` - JSON. Must contain a single JSON _object_ (not an array).
152
#
153
# _NOTE: The default varfile format will change to YAML in Garden v0.13, since YAML allows for definition of nested
154
# objects and arrays._
155
#
156
# If you don't set the field and the `garden.env` file does not exist, we simply ignore it.
157
# If you do override the default value and the file doesn't exist, an error will be thrown.
158
#
159
# _Note that in many cases it is advisable to only use environment-specific var files, instead of combining
160
# multiple ones. See the `environments[].varfile` field for this option._
161
varfile: garden.env
162
​
163
# Key/value map of variables to configure for all environments. Keys may contain letters and numbers. Any values are
164
# permitted, including arrays and objects of any nesting.
165
variables: {}
Copied!

Project configuration keys

kind

Indicate what kind of config this is.
Type
Allowed Values
Default
Required
string
"Project"
"Project"
Yes

name

The name of the project.
Type
Required
string
Yes
Example:
1
name: "my-sweet-project"
Copied!

environments[]

A list of environments to configure for the project.
Type
Required
array[object]
No

environments[].name

​environments > name
The name of the environment.
Type
Required
string
Yes
Example:
1
environments:
2
- name: "dev"
Copied!

environments[].defaultNamespace

​environments > defaultNamespace
Set the default namespace to use. This can be templated to be user-specific, or to use an environment variable (e.g. in CI).
You can also set this to null, in order to require an explicit namespace to be set on usage. This may be advisable for shared environments, but you may also be able to achieve the desired result by templating this field, as mentioned above.
Type
Default
Required
string
"default"
No
Example:
1
environments:
2
- defaultNamespace: "user-${local.username}"
Copied!

environments[].production

​environments > production
Flag the environment as a production environment.
Setting this flag to true will activate the protection on the deploy, test, task, build, and dev commands. A protected command will ask for a user confirmation every time is run against an environment marked as production. Run the command with the "--yes" flag to skip the check (e.g. when running Garden in CI).
This flag is also passed on to every provider, and may affect how certain providers behave. For more details please check the documentation for the providers in use.
Type
Default
Required
boolean
false
No
Example:
1
environments:
2
- production: true
Copied!

environments[].providers[]

​environments > providers
DEPRECATED - Please use the top-level providers field instead, and if needed use the environments key on the provider configurations to limit them to specific environments.
Type
Default
Required
array[object]
[]
No

environments[].providers[].name

​environments > providers > name
The name of the provider plugin to use.
Type
Required
string
Yes
Example:
1
environments:
Copied!

environments[].providers[].dependencies[]

​environments > providers > dependencies
List other providers that should be resolved before this one.
Type
Default
Required
array[string]
[]
No
Example:
1
environments:
Copied!

environments[].providers[].environments[]

​environments > providers > environments
If specified, this provider will only be used in the listed environments. Note that an empty array effectively disables the provider. To use a provider in all environments, omit this field.
Type
Required
array[string]
No
Example:
1
environments:
Copied!

environments[].varfile

​environments > varfile
Specify a path (relative to the project root) to a file containing variables, that we apply on top of the environment-specific variables field.
The format of the files is determined by the configured file's extension:
  • .env - Standard "dotenv" format, as defined by dotenv.
  • .yaml/.yml - YAML. The file must consist of a YAML document, which must be a map (dictionary). Keys may contain any value type.
  • .json - JSON. Must contain a single JSON object (not an array).
NOTE: The default varfile format will change to YAML in Garden v0.13, since YAML allows for definition of nested objects and arrays.
If you don't set the field and the garden.<env-name>.env file does not exist, we simply ignore it. If you do override the default value and the file doesn't exist, an error will be thrown.
Type
Required
posixPath
No
Example:
1
environments:
2
- varfile: "custom.env"
Copied!

environments[].variables

​environments > variables
A key/value map of variables that modules can reference when using this environment. These take precedence over variables defined in the top-level variables field, but may also reference the top-level variables in template strings.
Type
Default
Required
object
{}
No

providers[]

A list of providers that should be used for this project, and their configuration. Please refer to individual plugins/providers for details on how to configure them.
Type
Default
Required
array[object]
[]
No

providers[].name

​providers > name
The name of the provider plugin to use.
Type
Required
string
Yes
Example:
1
providers:
2
- name: "local-kubernetes"
Copied!

providers[].dependencies[]

​providers > dependencies
List other providers that should be resolved before this one.
Type
Default
Required
array[string]
[]
No
Example:
1
providers:
2
- dependencies:
3
- exec
Copied!

providers[].environments[]

​providers > environments
If specified, this provider will only be used in the listed environments. Note that an empty array effectively disables the provider. To use a provider in all environments, omit this field.
Type
Required
array[string]
No
Example:
1
providers:
2
- environments:
3
- dev
4
- stage
Copied!

defaultEnvironment

The default environment to use when calling commands without the --env parameter. May include a namespace name, in the format <namespace>.<environment>. Defaults to the first configured environment, with no namespace set.
Type
Default
Required
string
""
No
Example:
1
defaultEnvironment: "dev"
Copied!

dotIgnoreFiles[]

Specify a list of filenames that should be used as ".ignore" files across the project, using the same syntax and semantics as .gitignore files. By default, patterns matched in .gardenignore files, found anywhere in the project, are ignored when scanning for modules and module sources (Note: prior to version 0.12.0, .gitignore files were also used by default). Note that these take precedence over the project module.include field, and module include fields, so any paths matched by the .ignore files will be ignored even if they are explicitly specified in those fields. See the Configuration Files guide for details.
Type
Default
Required
array[posixPath]
[".gardenignore"]
No
Example:
1
dotIgnoreFiles:
2
- .gardenignore
3
- .gitignore
Copied!

modules

Control where to scan for modules in the project.
Type
Required
object
No

modules.include[]

​modules > include
Specify a list of POSIX-style paths or globs that should be scanned for Garden modules.
Note that you can also exclude path using the exclude field or by placing .gardenignore files in your source tree, which use the same format as .gitignore files. See the Configuration Files guide for details.
Unlike the exclude field, the paths/globs specified here have no effect on which files and directories Garden watches for changes. Use the exclude field to affect those, if you have large directories that should not be watched for changes.
Also note that specifying an empty list here means no paths should be included.
Type
Required
array[posixPath]
No
Example:
1
modules:
2
...
3
include:
4
- modules/**/*
Copied!

modules.exclude[]

​modules > exclude
Specify a list of POSIX-style paths or glob patterns that should be excluded when scanning for modules.
The filters here also affect which files and directories are watched for changes. So if you have a large number of directories in your project that should not be watched, you should specify them here.
For example, you might want to exclude large vendor directories in your project from being scanned and watched, by setting exclude: [node_modules/**/*, vendor/**/*].
Note that you can also explicitly include files using the include field. If you also specify the include field, the paths/patterns specified here are filtered from the files matched by include.
The include field does not affect which files are watched.
See the Configuration Files guide for details.
Type
Required
array[posixPath]
No
Example:
1
modules:
2
...
3
exclude:
4
- public/**/*
5
- tmp/**/*
Copied!

outputs[]

A list of output values that the project should export. These are exported by the garden get outputs command, as well as when referencing a project as a sub-project within another project.
You may use any template strings to specify the values, including references to provider outputs, module outputs and runtime outputs. For a full reference, see the Output configuration context section in the Template String Reference.
Note that if any runtime outputs are referenced, the referenced services and tasks will be deployed and run if necessary when resolving the outputs.
Type
Default
Required
array[object]
[]
No

outputs[].name

​outputs > name
The name of the output value.
Type
Required
string
Yes
Example:
1
outputs:
2
- name: "my-output-key"
Copied!

outputs[].value

​outputs > value
The value for the output. Must be a primitive (string, number, boolean or null). May also be any valid template string.
Type
Required
​
​
`number
string
boolean`
Yes
Example:
1
outputs:
2
- value: "${modules.my-module.outputs.some-output}"
Copied!

sources[]

A list of remote sources to import into project.
Type
Default
Required
array[object]
[]
No

sources[].name

​sources > name
The name of the source to import
Type
Required
string
Yes
Example:
1
sources:
2
- name: "my-external-repo"
Copied!

sources[].repositoryUrl

​sources > repositoryUrl
A remote repository URL. Currently only supports git servers. Must contain a hash suffix pointing to a specific branch or tag, with the format: #
Type
Required
​
`gitUrl
string`
Yes
Example:
1
sources:
2
- repositoryUrl: "git+https://github.com/org/repo.git#v2.0"
Copied!

varfile

Specify a path (relative to the project root) to a file containing variables, that we apply on top of the project-wide variables field.
The format of the files is determined by the configured file's extension:
  • .env - Standard "dotenv" format, as defined by dotenv.
  • .yaml/.yml - YAML. The file must consist of a YAML document, which must be a map (dictionary). Keys may contain any value type.
  • .json - JSON. Must contain a single JSON object (not an array).
NOTE: The default varfile format will change to YAML in Garden v0.13, since YAML allows for definition of nested objects and arrays.
If you don't set the field and the garden.env file does not exist, we simply ignore it. If you do override the default value and the file doesn't exist, an error will be thrown.
Note that in many cases it is advisable to only use environment-specific var files, instead of combining multiple ones. See the environments[].varfile field for this option.
Type
Default
Required
posixPath
"garden.env"
No
Example:
1
varfile: "custom.env"
Copied!

variables

Key/value map of variables to configure for all environments. Keys may contain letters and numbers. Any values are permitted, including arrays and objects of any nesting.
Type
Default
Required
object
{}
No

Module YAML schema

1
# The schema version of this config (currently not used).
2
apiVersion: garden.io/v0
3
​
4
kind: Module
5
​
6
# The type of this module.
7
type:
8
​
9
# The name of this module.
10
name:
11
​
12
# Specify how to build the module. Note that plugins may define additional keys on this object.
13
build:
14
# A list of modules that must be built before this module is built.
15
dependencies:
16
- # Module name to build ahead of this module.
17
name:
18
​
19
# Specify one or more files or directories to copy from the built dependency to this module.
20
copy:
21
- # POSIX-style path or filename of the directory or file(s) to copy to the target.
22
source:
23
​
24
# POSIX-style path or filename to copy the directory or file(s), relative to the build directory.
25
# Defaults to to same as source path.
26
target: ''
27
​
28
# A description of the module.
29
description:
30
​
31
# Set this to `true` to disable the module. You can use this with conditional template strings to disable modules
32
# based on, for example, the current environment or other variables (e.g. `disabled: \${environment.name == "prod"}`).
33
# This can be handy when you only need certain modules for specific environments, e.g. only for development.
34
#
35
# Disabling a module means that any services, tasks and tests contained in it will not be deployed or run. It also
36
# means that the module is not built _unless_ it is declared as a build dependency by another enabled module (in which
37
# case building this module is necessary for the dependant to be built).
38
#
39
# If you disable the module, and its services, tasks or tests are referenced as _runtime_ dependencies, Garden will
40
# automatically ignore those dependency declarations. Note however that template strings referencing the module's
41
# service or task outputs (i.e. runtime outputs) will fail to resolve when the module is disabled, so you need to make
42
# sure to provide alternate values for those if you're using them, using conditional expressions.
43
disabled: false
44
​
45
# Specify a list of POSIX-style paths or globs that should be regarded as the source files for this module. Files that
46
# do *not* match these paths or globs are excluded when computing the version of the module, when responding to
47
# filesystem watch events, and when staging builds.
48
#
49
# Note that you can also _exclude_ files using the `exclude` field or by placing `.gardenignore` files in your source
50
# tree, which use the same format as `.gitignore` files. See the [Configuration Files
51
# guide](https://docs.garden.io/using-garden/configuration-overview#including-excluding-files-and-directories) for
52
# details.
53
#
54
# Also note that specifying an empty list here means _no sources_ should be included.
55
include:
56
​
57
# Specify a list of POSIX-style paths or glob patterns that should be excluded from the module. Files that match these
58
# paths or globs are excluded when computing the version of the module, when responding to filesystem watch events,
59
# and when staging builds.
60
#
61
# Note that you can also explicitly _include_ files using the `include` field. If you also specify the `include`
62
# field, the files/patterns specified here are filtered from the files matched by `include`. See the [Configuration
63
# Files guide](https://docs.garden.io/using-garden/configuration-overview#including-excluding-files-and-directories)
64
# for details.
65
#
66
# Unlike the `modules.exclude` field in the project config, the filters here have _no effect_ on which files and
67
# directories are watched for changes. Use the project `modules.exclude` field to affect those, if you have large
68
# directories that should not be watched for changes.
69
exclude:
70
​
71
# A remote repository URL. Currently only supports git servers. Must contain a hash suffix pointing to a specific
72
# branch or tag, with the format: <git remote url>#<branch|tag>
73
#
74
# Garden will import the repository source code into this module, but read the module's config from the local
75
# garden.yml file.
76
repositoryUrl:
77
​
78
# When false, disables pushing this module to remote registries.
79
allowPublish: true
80
​
81
# A list of files to write to the module directory when resolving this module. This is useful to automatically
82
# generate (and template) any supporting files needed for the module.
83
generateFiles:
84
- # POSIX-style filename to read the source file contents from, relative to the path of the ModuleTemplate
85
# configuration file.
86
# This file may contain template strings, much like any other field in the configuration.
87
sourcePath:
88
​
89
# POSIX-style filename to write the resolved file contents to, relative to the path of the Bundle that references
90
# the template.
91
#
92
# Note that any existing file with the same name will be overwritten. If the path contains one or more
93
# directories, they will be automatically created if missing.
94
targetPath:
95
​
96
# The desired file contents as a string.
97
value:
Copied!

Module configuration keys

apiVersion

The schema version of this config (currently not used).
Type
Allowed Values
Default
Required
string
"garden.io/v0"
"garden.io/v0"
Yes

kind

Type
Allowed Values
Default
Required
string
"Module"
"Module"
Yes

type

The type of this module.
Type
Required
string
Yes
Example:
1
type: "container"
Copied!

name

The name of this module.
Type
Required
string
Yes
Example:
1
name: "my-sweet-module"
Copied!

build

Specify how to build the module. Note that plugins may define additional keys on this object.
Type
Default
Required
object
{"dependencies":[]}
No

build.dependencies[]

​build > dependencies
A list of modules that must be built before this module is built.
Type
Default
Required
array[object]
[]
No
Example:
1
build:
2
...
3
dependencies:
4
- name: some-other-module-name
Copied!

build.dependencies[].name

​build > dependencies > name
Module name to build ahead of this module.
Type
Required
string
Yes

build.dependencies[].copy[]

​build > dependencies > copy
Specify one or more files or directories to copy from the built dependency to this module.
Type
Default
Required
array[object]
[]
No

build.dependencies[].copy[].source

​build > dependencies > copy > source
POSIX-style path or filename of the directory or file(s) to copy to the target.
Type
Required
posixPath
Yes

build.dependencies[].copy[].target

​build > dependencies > copy > target
POSIX-style path or filename to copy the directory or file(s), relative to the build directory. Defaults to to same as source path.
Type
Default
Required
posixPath
""
No

description

A description of the module.
Type
Required
string
No

disabled

Set this to true to disable the module. You can use this with conditional template strings to disable modules based on, for example, the current environment or other variables (e.g. disabled: \${environment.name == "prod"}). This can be handy when you only need certain modules for specific environments, e.g. only for development.
Disabling a module means that any services, tasks and tests contained in it will not be deployed or run. It also means that the module is not built unless it is declared as a build dependency by another enabled module (in which case building this module is necessary for the dependant to be built).
If you disable the module, and its services, tasks or tests are referenced as runtime dependencies, Garden will automatically ignore those dependency declarations. Note however that template strings referencing the module's service or task outputs (i.e. runtime outputs) will fail to resolve when the module is disabled, so you need to make sure to provide alternate values for those if you're using them, using conditional expressions.
Type
Default
Required
boolean
false
No

include[]

Specify a list of POSIX-style paths or globs that should be regarded as the source files for this module. Files that do not match these paths or globs are excluded when computing the version of the module, when responding to filesystem watch events, and when staging builds.
Note that you can also exclude files using the exclude field or by placing .gardenignore files in your source tree, which use the same format as .gitignore files. See the Configuration Files guide for details.
Also note that specifying an empty list here means no sources should be included.
Type
Required
array[posixPath]
No
Example:
1
include:
2
- Dockerfile
3
- my-app.js
Copied!

exclude[]

Specify a list of POSIX-style paths or glob patterns that should be excluded from the module. Files that match these paths or globs are excluded when computing the version of the module, when responding to filesystem watch events, and when staging builds.
Note that you can also explicitly include files using the include field. If you also specify the include field, the files/patterns specified here are filtered from the files matched by include. See the Configuration Files guide for details.
Unlike the modules.exclude field in the project config, the filters here have no effect on which files and directories are watched for changes. Use the project modules.exclude field to affect those, if you have large directories that should not be watched for changes.
Type
Required
array[posixPath]
No
Example:
1
exclude:
2
- tmp/**/*
3
- '*.log'
Copied!

repositoryUrl

A remote repository URL. Currently only supports git servers. Must contain a hash suffix pointing to a specific branch or tag, with the format: #
Garden will import the repository source code into this module, but read the module's config from the local garden.yml file.
Type
Required
​
`gitUrl
string`
No
Example:
1
repositoryUrl: "git+https://github.com/org/repo.git#v2.0"
Copied!

allowPublish

When false, disables pushing this module to remote registries.
Type
Default
Required
boolean
true
No

generateFiles[]

A list of files to write to the module directory when resolving this module. This is useful to automatically generate (and template) any supporting files needed for the module.
Type
Required
array[object]
No

generateFiles[].sourcePath

​generateFiles > sourcePath
POSIX-style filename to read the source file contents from, relative to the path of the ModuleTemplate configuration file. This file may contain template strings, much like any other field in the configuration.
Type
Required
posixPath
No

generateFiles[].targetPath

​generateFiles > targetPath
POSIX-style filename to write the resolved file contents to, relative to the path of the Bundle that references the template.
Note that any existing file with the same name will be overwritten. If the path contains one or more directories, they will be automatically created if missing.
Type
Required
posixPath
Yes

generateFiles[].value

​generateFiles > value
The desired file contents as a string.
Type
Required
string
No

Workflow YAML schema

1
# The schema version of this workflow's config (currently not used).
2
apiVersion: garden.io/v0
3
​
4
kind: Workflow
5
​
6
# The name of this workflow.
7
name:
8
​
9
# A description of the workflow.
10
description:
11
​
12
# A list of files to write before starting the workflow.
13
#
14
# This is useful to e.g. create files required for provider authentication, and can be created from data stored in
15
# secrets or templated strings.
16
#
17
# Note that you cannot reference provider configuration in template strings within this field, since they are resolved
18
# after these files are generated. This means you can reference the files specified here in your provider
19
# configurations.
20
files:
21
- # POSIX-style path to write the file to, relative to the project root (or absolute). If the path contains one
22
# or more directories, they are created automatically if necessary.
23
# If any of those directories conflict with existing file paths, or if the file path conflicts with an existing
24
# directory path, an error will be thrown.
25
# **Any existing file with the same path will be overwritten, so be careful not to accidentally accidentally
26
# overwrite files unrelated to your workflow.**
27
path:
28
​
29
# The file data as a string.
30
data:
31
​
32
# The name of a Garden secret to copy the file data from (Garden Enterprise only).
33
secretName:
34
​
35
# The number of hours to keep the workflow pod running after completion.
36
keepAliveHours: 48
37
​
38
limits:
39
# The maximum amount of CPU the workflow pod can use, in millicpus (i.e. 1000 = 1 CPU)
40
cpu: 1000
41
​
42
# The maximum amount of RAM the workflow pod can use, in megabytes (i.e. 1024 = 1 GB)
43
memory: 1024
44
​
45
# The steps the workflow should run. At least one step is required. Steps are run sequentially. If a step fails,
46
# subsequent steps are skipped.
47
steps:
48
- # An identifier to assign to this step. If none is specified, this defaults to "step-<number of step>", where
49
# <number of step> is the sequential number of the step (first step being number 1).
50
#
51
# This identifier is useful when referencing command outputs in following steps. For example, if you set this
52
# to "my-step", following steps can reference the \${steps.my-step.outputs.*} key in the `script` or `command`
53
# fields.
54
name:
55
​
56
# A Garden command this step should run, followed by any required or optional arguments and flags.
57
# Arguments and options for the commands may be templated, including references to previous steps, but for now
58
# the commands themselves (as listed below) must be hard-coded.
59
#
60
# Supported commands:
61
#
62
# `[build]`
63
# `[delete, environment]`
64
# `[delete, service]`
65
# `[deploy]`
66
# `[exec]`
67
# `[get, config]`
68
# `[get, outputs]`
69
# `[get, status]`
70
# `[get, task-result]`
71
# `[get, test-result]`
72
# `[link, module]`
73
# `[link, source]`
74
# `[publish]`
75
# `[run, task]`
76
# `[run, test]`
77
# `[test]`
78
# `[update-remote, all]`
79
# `[update-remote, modules]`
80
# `[update-remote, sources]`
81
#
82
#
83
command:
84
​
85
# A description of the workflow step.
86
description:
87
​
88
# A bash script to run. Note that the host running the workflow must have bash installed and on path.
89
# It is considered to have run successfully if it returns an exit code of 0. Any other exit code signals an error,
90
# and the remainder of the workflow is aborted.
91
#
92
# The script may include template strings, including references to previous steps.
93
script:
94
​
95
# Set to true to skip this step. Use this with template conditionals to skip steps for certain environments or
96
# scenarios.
97
skip: false
98
​
99
# A list of triggers that determine when the workflow should be run, and which environment should be used (Garden
100
# Enterprise only).
101
triggers:
102
- # The environment name (from your project configuration) to use for the workflow when matched by this trigger.
103
environment:
104
​
105
# The namespace to use for the workflow when matched by this trigger. Follows the namespacing setting used for
106
# this trigger's environment, as defined in your project's environment configs.
107
namespace:
108
​
109
# A list of [GitHub events](https://docs.github.com/en/developers/webhooks-and-events/webhook-events-and-payloads)
110
# that should trigger this workflow.
111
#
112
# Supported events:
113
#
114
# `create`, `pull-request`, `pull-request-closed`, `pull-request-created`, `pull-request-opened`,
115
# `pull-request-updated`, `push`, `release`, `release-created`, `release-deleted`, `release-edited`,
116
# `release-prereleased`, `release-published`, `release-unpublished`
117
#
118
#
119
events:
120
​
121
# If specified, only run the workflow for branches matching one of these filters.
122
branches:
123
​
124
# If specified, only run the workflow for tags matching one of these filters.
125
tags:
126
​
127
# If specified, do not run the workflow for branches matching one of these filters.
128
ignoreBranches:
129
​
130
# If specified, do not run the workflow for tags matching one of these filters.
131
ignoreTags:
Copied!

Workflow configuration keys

apiVersion

The schema version of this workflow's config (currently not used).
Type
Allowed Values
Default
Required
string
"garden.io/v0"
"garden.io/v0"
Yes

kind

Type
Allowed Values
Default
Required
string
"Workflow"
"Workflow"
Yes

name

The name of this workflow.
Type
Required
string
Yes
Example:
1
name: "my-workflow"
Copied!

description

A description of the workflow.
Type
Required
string
No

files[]

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.
Type
Required
array[object]
No

files[].path

​files > path
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 accidentally overwrite files unrelated to your workflow.
Type
Required
posixPath
No
Example:
1
files:
2
- path: ".auth/kubeconfig.yaml"
Copied!

files[].data

​files > data
The file data as a string.
Type
Required
string
No

files[].secretName

​files > secretName
The name of a Garden secret to copy the file data from (Garden Enterprise only).
Type
Required
string
No

keepAliveHours

The number of hours to keep the workflow pod running after completion.
Type
Default
Required
number
48
No

limits

Type
Default
Required
object
{"cpu":1000,"memory":1024}
No