# The schema version of this config (currently not used).
# The type of this module.
# The name of this module.
# Specify how to build the module. Note that plugins may define additional keys on this object.
# A list of modules that must be built before this module is built.
- # Module name to build ahead of this module.
# Specify one or more files or directories to copy from the built dependency to this module.
- # POSIX-style path or filename of the directory or file(s) to copy to the 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.
# Maximum time in seconds to wait for build to finish.
# The command to run to perform the build.
# By default, the command is run inside the Garden build directory (under .garden/build/<module-name>).
# If the top level `local` directive is set to `true`, the command runs in the module source directory instead.
# A description of the module.
# 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.
# 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](https://docs.garden.io/using-garden/configuration-overview#including-excluding-files-and-directories) for
# Also note that specifying an empty list here means _no sources_ should be included.
# 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](https://docs.garden.io/using-garden/configuration-overview#including-excluding-files-and-directories)
# 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.
# A remote repository URL. Currently only supports git servers. Must contain a hash suffix pointing to a specific
# branch or tag, with the format: <git remote url>#<branch|tag>
# Garden will import the repository source code into this module, but read the module's config from the local
# When false, disables pushing this module to remote registries.
# 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.
- # POSIX-style filename to read the source file contents from, relative to the path of the module (or the
# ModuleTemplate configuration file if one is being applied).
# This file may contain template strings, much like any other field in the configuration.
# POSIX-style filename to write the resolved file contents to, relative to the path of the module source directory
# (for remote modules this means the root of the module repository, otherwise the directory of the module
# 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.
# By default, Garden will attempt to resolve any Garden template strings in source files. Set this to false to
# skip resolving template strings. Note that this does not apply when setting the `value` field, since that's
# resolved earlier when parsing the configuration.
# The desired file contents as a string.
# A map of variables scoped to this particular module. These are resolved before any other parts of the module
# configuration and take precedence over project-scoped variables. They may reference project-scoped variables, and
# generally use any template strings normally allowed when resolving modules.
# Specify a path (relative to the module root) to a file containing variables, that we apply on top of the
# module-level `variables` field.
# The format of the files is determined by the configured file's extension:
# * `.env` - Standard "dotenv" format, as defined by [dotenv](https://github.com/motdotla/dotenv#rules).
# * `.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
# To use different module-level varfiles in different environments, you can template in the environment name
# to the varfile name, e.g. `varfile: "my-module.\$\{environment.name\}.env` (this assumes that the corresponding
# If set to true, Garden will run the build command, services, tests, and tasks in the module source directory,
# instead of in the Garden build directory (under .garden/build/<module-name>).
# Garden will therefore not stage the build for local exec modules. This means that include/exclude filters
# and ignore files are not applied to local exec modules.
# Key/value map of environment variables. Keys must be valid POSIX environment variable names (must not start with
# `GARDEN`) and values must be primitives.
# A list of services to deploy from this module.
- # Valid RFC1035/RFC1123 (DNS) label (may contain lowercase letters, numbers and dashes, must start with a letter,
# and cannot end with a dash), cannot contain consecutive dashes or start with `garden`, or be longer than 63
# The names of any services that this service depends on at runtime, and the names of any tasks that should be
# executed before this service is deployed.
# Set this to `true` to disable the service. You can use this with conditional template strings to enable/disable
# services based on, for example, the current environment or other variables (e.g. `enabled: \${environment.name
# != "prod"}`). This can be handy when you only need certain services for specific environments, e.g. only for
# Disabling a service means that it will not be deployed, and will also be ignored if it is declared as a runtime
# dependency for another service, test or task.
# Note however that template strings referencing the service's outputs (i.e. runtime outputs) will fail to resolve
# when the service is disabled, so you need to make sure to provide alternate values for those if you're using
# them, using conditional expressions.
# The command to run to deploy the service.
# By default, the command is run inside the Garden build directory (under .garden/build/<module-name>).
# If the top level `local` directive is set to `true`, the command runs in the module source directory instead.
# Optionally set a command to check the status of the service. If this is specified, it is run before the
# `deployCommand`. If the command runs successfully and returns exit code of 0, the service is considered
# already deployed and the `deployCommand` is not run.
# If this is not specified, the service is always reported as "unknown", so it's highly recommended to specify
# this command if possible.
# By default, the command is run inside the Garden build directory (under .garden/build/<module-name>).
# If the top level `local` directive is set to `true`, the command runs in the module source directory instead.
# Optionally set a command to clean the service up, e.g. when running `garden delete env`.
# By default, the command is run inside the Garden build directory (under .garden/build/<module-name>).
# If the top level `local` directive is set to `true`, the command runs in the module source directory instead.
# The maximum duration (in seconds) to wait for a local script to exit.
# Environment variables to set when running the deploy and status commands.
# The commmand to run to deploy the service in dev mode. When in dev mode, Garden assumes that
# the command starts a persistent process and does not wait for it return. The logs from the process
# can be retrieved via the `garden logs` command as usual.
# If a `statusCommand` is set, Garden will wait until it returns a zero exit code before considering
# the service ready. Otherwise it considers the service immediately ready.
# By default, the command is run inside the Garden build directory (under .garden/build/<module-name>).
# If the top level `local` directive is set to `true`, the command runs in the module source directory instead.
# Optionally set a command to check the status of the service in dev mode. Garden will run the status command
# at an interval until it returns a zero exit code or times out.
# If no `statusCommand` is set, Garden will consider the service ready as soon as it has started the process.
# By default, the command is run inside the Garden build directory (under .garden/build/<module-name>).
# If the top level `local` directive is set to `true`, the command runs in the module source directory instead.
# The maximum duration (in seconds) to wait for a for the `statusCommand` to return a zero
# exit code. Ignored if no `statusCommand` is set.
# A list of tasks that can be run in this module.
- # The name of the task.
# A description of the task.
# The names of any tasks that must be executed, and the names of any services that must be running, before this
# Set this to `true` to disable the task. You can use this with conditional template strings to enable/disable
# tasks based on, for example, the current environment or other variables (e.g. `enabled: \${environment.name !=
# "prod"}`). This can be handy when you only want certain tasks to run in specific environments, e.g. only for
# Disabling a task means that it will not be run, and will also be ignored if it is declared as a runtime
# dependency for another service, test or task.
# Note however that template strings referencing the task's outputs (i.e. runtime outputs) will fail to resolve
# when the task is disabled, so you need to make sure to provide alternate values for those if you're using them,
# using conditional expressions.
# Maximum duration (in seconds) of the task's execution.
# A list of artifacts to copy after the task run.
- # A POSIX-style path or glob to copy, relative to the build root.
# A POSIX-style path to copy the artifacts to, relative to the project artifacts directory at
# By default, the command is run inside the Garden build directory (under .garden/build/<module-name>).
# If the top level `local` directive is set to `true`, the command runs in the module source directory instead.
# Environment variables to set when running the command.
# A list of tests to run in the module.
- # The name of the test.
# The names of any services that must be running, and the names of any tasks that must be executed, before the
# Set this to `true` to disable the test. You can use this with conditional template strings to
# enable/disable tests based on, for example, the current environment or other variables (e.g.
# `enabled: \${environment.name != "prod"}`). This is handy when you only want certain tests to run in
# specific environments, e.g. only during CI.
# Maximum duration (in seconds) of the test run.
# The command to run to test the module.
# By default, the command is run inside the Garden build directory (under .garden/build/<module-name>).
# If the top level `local` directive is set to `true`, the command runs in the module source directory instead.
# Environment variables to set when running the command.
# A list of artifacts to copy after the test run.
- # A POSIX-style path or glob to copy, relative to the build root.
# A POSIX-style path to copy the artifacts to, relative to the project artifacts directory at