# 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.
# 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.
# If neither `include` nor `exclude` is set, and the module has local chart sources, Garden
# automatically sets `include` to: `["*", "charts/**/*", "templates/**/*"]`.
# If neither `include` nor `exclude` is set and the module specifies a remote chart, Garden
# automatically sets `ìnclude` to `[]`.
# 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
# Whether to set the --atomic flag during installs and upgrades. Set to false if e.g. you want to see more information
# about failures and then manually roll back, instead of having Helm do it automatically on failure.
# The name of another `helm` module to use as a base for this one. Use this to re-use a Helm chart across multiple
# services. For example, you might have an organization-wide base chart for certain types of services.
# If set, this module will by default inherit the following properties from the base module: `serviceResource`,
# Each of those can be overridden in this module. They will be merged with a JSON Merge Patch (RFC 7396).
# A valid Helm chart name or URI (same as you'd input to `helm install`). Required if the module doesn't contain the
# The path, relative to the module path, to the chart sources (i.e. where the Chart.yaml file is, if any). Not used
# when `base` is specified.
# List of names of services that should be deployed before this chart.
# Specifies which files or directories to sync to which paths inside the running containers of the service when it's
# in dev mode, and overrides for the container command and/or arguments.
# Note that `serviceResource` must also be specified to enable dev mode.
# Dev mode is enabled when running the `garden dev` command, and by setting the `--dev` flag on the `garden deploy`
# See the [Code Synchronization guide](https://docs.garden.io/guides/code-synchronization-dev-mode) for more
# Override the default container arguments when in dev mode.
# Override the default container command (i.e. entrypoint) when in dev mode.
# Specify one or more source files or directories to automatically sync with the running container.
- # POSIX-style path of the directory to sync to the target, relative to the module's top-level directory. Must be
# a relative path. Defaults to the module's top-level directory if no value is provided.
# POSIX-style absolute path to sync the directory to inside the container. The root path (i.e. "/") is not
# Specify a list of POSIX-style paths or glob patterns that should be excluded from the sync.
# `.git` directories and `.garden` directories are always ignored.
# The sync mode to use for the given paths. See the [Dev Mode
# guide](https://docs.garden.io/guides/code-synchronization-dev-mode) for details.
# The default permission bits, specified as an octal, to set on files at the sync target. Defaults to 0600 (user
# read/write). See the [Mutagen docs](https://mutagen.io/documentation/synchronization/permissions#permissions)
# The default permission bits, specified as an octal, to set on directories at the sync target. Defaults to 0700
# (user read/write). See the [Mutagen
# docs](https://mutagen.io/documentation/synchronization/permissions#permissions) for more information.
# Set the default owner of files and directories at the target. Specify either an integer ID or a string name.
# See the [Mutagen docs](https://mutagen.io/documentation/synchronization/permissions#owners-and-groups) for
# Set the default group on files and directories at the target. Specify either an integer ID or a string name.
# See the [Mutagen docs](https://mutagen.io/documentation/synchronization/permissions#owners-and-groups) for
# Optionally specify the name of a specific container to sync to. If not specified, the first container in the
# A valid Kubernetes namespace name. Must be a valid RFC1035/RFC1123 (DNS) label (may contain lowercase letters,
# numbers and dashes, must start with a letter, and cannot end with a dash) and must not be longer than 63 characters.
# Manually specify port forwards that Garden should set up when deploying in dev or watch mode. If specified, these
# override the auto-detection of forwardable ports, so you'll need to specify the full list of port forwards to
- # An identifier to describe the port forward.
# The full resource kind and name to forward to, e.g. Service/my-service or Deployment/my-deployment. Note that
# Garden will not validate this ahead of attempting to start the port forward, so you need to make sure this is
# correctly set. The types of resources supported will match that of the `kubectl port-forward` CLI command.
# The port number on the remote resource to forward to.
# The _preferred_ local port to forward from. If none is set, a random port is chosen. If the specified port is
# not available, a warning is shown and a random port chosen instead.
# Optionally override the release name used when installing (defaults to the module name).
# The repository URL to fetch the chart from.
# The Deployment, DaemonSet or StatefulSet or Pod that Garden should regard as the _Garden service_ in this module
# (not to be confused with Kubernetes Service resources).
# This can either reference a workload (i.e. a Deployment, DaemonSet or StatefulSet) via the `kind` and `name` fields,
# or a Pod via the `podSelector` field.
# Because a Helm chart can contain any number of Kubernetes resources, this needs to be specified for certain Garden
# features and commands to work, such as hot-reloading.
# The type of Kubernetes resource to sync files to.
# The name of a container in the target. Specify this if the target contains more than one container and the main
# container is not the first container in the spec.
# A map of string key/value labels to match on any Pods in the namespace. When specified, a random ready Pod with
# matching labels will be picked as a target, so make sure the labels will always match a specific Pod type.
# The name of the resource to sync to. If the chart contains a single resource of the specified Kind,
# This can include a Helm template string, e.g. '{{ template "my-chart.fullname" . }}'.
# This allows you to easily match the dynamic names given by Helm. In most cases you should copy this
# directly from the template in question in order to match it. Note that you may need to add single quotes around
# the string for the YAML to be parsed correctly.
# The Garden module that contains the sources for the container. This needs to be specified under `serviceResource`
# in order to enable hot-reloading and dev mode, but is not necessary for tasks and tests.
# Must be a `container` module, and for hot-reloading to work you must specify the `hotReload` field on the
# container module (not required for dev mode).
# _Note: If you specify a module here, you don't need to specify it additionally under `build.dependencies`._
# If specified, overrides the arguments for the main container when running in hot-reload mode.
# Set this to true if the chart should only be built, but not deployed as a service. Use this, for example, if the
# chart should only be used as a base for other modules.
# The task definitions for 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.
# Set to false if you don't want the task's result to be cached. Use this if the task needs to be run any time
# your project (or one or more of the task's dependants) is deployed. Otherwise the task is only re-run when its
# version changes (i.e. the module or one of its dependencies is modified), or when you run `garden run task`.
# The command/entrypoint used to run the task inside the container.
# The arguments to pass to the container used for execution.
# Key/value map of environment variables. Keys must be valid POSIX environment variable names (must not start with
# `GARDEN`) and values must be primitives or references to secrets.
# Specify artifacts to copy out of the container after the run. The artifacts are stored locally under
# the `.garden/artifacts` directory.
- # A POSIX-style path or glob to copy. Must be an absolute path. May contain wildcards.
# A POSIX-style path to copy the artifacts to, relative to the project artifacts directory at
# The Deployment, DaemonSet or StatefulSet or Pod that Garden should use to execute this task.
# If not specified, the `serviceResource` configured on the module will be used. If neither is specified,
# an error will be thrown.
# This can either reference a workload (i.e. a Deployment, DaemonSet or StatefulSet) via the `kind` and `name`
# fields, or a Pod via the `podSelector` field.
# The following pod spec fields from the service resource will be used (if present) when executing the task:
# * `automountServiceAccountToken`
# * `shareProcessNamespace`
# * `topologySpreadConstraints`
# The type of Kubernetes resource to sync files to.
# The name of a container in the target. Specify this if the target contains more than one container and the
# main container is not the first container in the spec.
# A map of string key/value labels to match on any Pods in the namespace. When specified, a random ready Pod
# with matching labels will be picked as a target, so make sure the labels will always match a specific Pod
# The name of the resource to sync to. If the chart contains a single resource of the specified Kind,
# This can include a Helm template string, e.g. '{{ template "my-chart.fullname" . }}'.
# This allows you to easily match the dynamic names given by Helm. In most cases you should copy this
# directly from the template in question in order to match it. Note that you may need to add single quotes
# the string for the YAML to be parsed correctly.
# The Garden module that contains the sources for the container. This needs to be specified under
# `serviceResource` in order to enable hot-reloading and dev mode, but is not necessary for tasks and tests.
# Must be a `container` module, and for hot-reloading to work you must specify the `hotReload` field on the
# container module (not required for dev mode).
# _Note: If you specify a module here, you don't need to specify it additionally under `build.dependencies`._
# If specified, overrides the arguments for the main container when running in hot-reload mode.
# The test suite definitions for this 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/entrypoint used to run the test inside the container.
# The arguments to pass to the container used for testing.
# Key/value map of environment variables. Keys must be valid POSIX environment variable names (must not start with
# `GARDEN`) and values must be primitives or references to secrets.
# Specify artifacts to copy out of the container after the run. The artifacts are stored locally under
# the `.garden/artifacts` directory.
- # A POSIX-style path or glob to copy. Must be an absolute path. May contain wildcards.
# A POSIX-style path to copy the artifacts to, relative to the project artifacts directory at
# The Deployment, DaemonSet or StatefulSet or Pod that Garden should use to execute this test suite.
# If not specified, the `serviceResource` configured on the module will be used. If neither is specified,
# an error will be thrown.
# This can either reference a workload (i.e. a Deployment, DaemonSet or StatefulSet) via the `kind` and `name`
# fields, or a Pod via the `podSelector` field.
# The following pod spec fields from the service resource will be used (if present) when executing the test suite:
# * `automountServiceAccountToken`
# * `shareProcessNamespace`
# * `topologySpreadConstraints`
# The type of Kubernetes resource to sync files to.
# The name of a container in the target. Specify this if the target contains more than one container and the
# main container is not the first container in the spec.
# A map of string key/value labels to match on any Pods in the namespace. When specified, a random ready Pod
# with matching labels will be picked as a target, so make sure the labels will always match a specific Pod
# The name of the resource to sync to. If the chart contains a single resource of the specified Kind,
# This can include a Helm template string, e.g. '{{ template "my-chart.fullname" . }}'.
# This allows you to easily match the dynamic names given by Helm. In most cases you should copy this
# directly from the template in question in order to match it. Note that you may need to add single quotes
# the string for the YAML to be parsed correctly.
# The Garden module that contains the sources for the container. This needs to be specified under
# `serviceResource` in order to enable hot-reloading and dev mode, but is not necessary for tasks and tests.
# Must be a `container` module, and for hot-reloading to work you must specify the `hotReload` field on the
# container module (not required for dev mode).
# _Note: If you specify a module here, you don't need to specify it additionally under `build.dependencies`._
# If specified, overrides the arguments for the main container when running in hot-reload mode.
# Time in seconds to wait for Helm to complete any individual Kubernetes operation (like Jobs for hooks).
# The chart version to deploy.
# Map of values to pass to Helm when rendering the templates. May include arrays and nested objects. When specified,
# these take precedence over the values in the `values.yaml` file (or the files specified in `valueFiles`).
# Specify value files to use when rendering the Helm chart. These will take precedence over the `values.yaml` file
# bundled in the Helm chart, and should be specified in ascending order of precedence. Meaning, the last file in
# this list will have the highest precedence.
# If you _also_ specify keys under the `values` field, those will effectively be added as another file at the end
# of this list, so they will take precedence over other files listed here.
# Note that the paths here should be relative to the _module_ root, and the files should be contained in