jib-container
Modules are deprecated and will be removed in version 0.14
. Please use action-based configuration instead. See the 0.12 to Bonsai migration guide for details.
Description
Extends the container type to build the image with Jib. Use this to efficiently build container images for Java services. Check out the jib example to see it in action.
The image is always built locally, directly from the source directory (see the note on that below), before shipping the container image to the right place. You can set build.tarOnly: true
to only build the image as a tarball.
By default (and when not using remote building), the image is pushed to the local Docker daemon, to match the behavior of and stay compatible with normal container
actions.
When using remote building with the kubernetes
provider, the image is synced to the cluster (where individual layers are cached) and then pushed to the deployment registry from there. This is to make sure any registry auth works seamlessly and exactly like for normal Docker image builds.
Please consult the Jib documentation for how to configure Jib in your Gradle or Maven project.
To provide additional arguments to Gradle/Maven when building, you can set the extraFlags
field.
Important note: Unlike many other types, jib-container
builds are done from the source directory instead of the build staging directory, because of how Java projects are often laid out across a repository. This means build dependency copy directives are effectively ignored, and any include/exclude statements and .gardenignore files will not impact the build result. _Note that you should still configure includes, excludes and/or a .gardenignore to tell Garden which files to consider as part of the Build version hash, to correctly detect whether a new build is required.**
Below is the full schema reference. For an introduction to configuring Garden modules, please look at our Configuration guide.
The first section contains the complete YAML schema, and the second section describes each schema key.
jib-container
modules also export values that are available in template strings. See the Outputs section below for details.
Complete YAML Schema
The values in the schema below are the default values.
Configuration Keys
kind
kind
type
type
The type of this module.
Example:
name
name
The name of this module.
Example:
build
build
Specify how to build the module. Note that plugins may define additional keys on this object.
build.dependencies[]
build.dependencies[]
build > dependencies
A list of modules that must be built before this module is built.
Example:
build.dependencies[].name
build.dependencies[].name
build > dependencies > name
Module name to build ahead of this module.
build.dependencies[].copy[]
build.dependencies[].copy[]
build > dependencies > copy
Specify one or more files or directories to copy from the built dependency to this module.
build.dependencies[].copy[].source
build.dependencies[].copy[].source
build > dependencies > copy > source
POSIX-style path or filename of the directory or file(s) to copy to the target.
build.dependencies[].copy[].target
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 the same as source path.
build.timeout
build.timeout
build > timeout
Maximum time in seconds to wait for build to finish.
build.projectType
build.projectType
build > projectType
The type of project to build. Defaults to auto-detecting between gradle and maven (based on which files/directories are found in the action root), but in some cases you may need to specify it.
build.jdkVersion
build.jdkVersion
build > jdkVersion
The JDK version to use.
The chosen version will be downloaded by Garden and used to define JAVA_HOME
environment variable for Gradle and Maven.
To use an arbitrary JDK distribution, please use the jdkPath
configuration option.
build.jdkPath
build.jdkPath
build > jdkPath
The JDK home path. This always overrides the JDK defined in jdkVersion
.
The value will be used as JAVA_HOME
environment variable for Gradle and Maven.
Example:
build.dockerBuild
build.dockerBuild
build > dockerBuild
Build the image and push to a local Docker daemon (i.e. use the jib:dockerBuild
/ jibDockerBuild
target).
build.tarOnly
build.tarOnly
build > tarOnly
Don't load or push the resulting image to a Docker daemon or registry, only build it as a tar file.
build.tarFormat
build.tarFormat
build > tarFormat
Specify the image format in the resulting tar file. Only used if tarOnly: true
.
build.gradlePath
build.gradlePath
build > gradlePath
Defines the location of the custom executable Gradle binary.
If not provided, then the Gradle binary available in the working directory will be used. If no Gradle binary found in the working dir, then Gradle 7.5.1 will be downloaded and used.
Note! Either jdkVersion
or jdkPath
will be used to define JAVA_HOME
environment variable for the custom Gradle. To ensure a system JDK usage, please set jdkPath
to ${local.env.JAVA_HOME}
.
build.mavenPath
build.mavenPath
build > mavenPath
Defines the location of the custom executable Maven binary.
If not provided, then Maven 3.8.8 will be downloaded and used.
Note! Either jdkVersion
or jdkPath
will be used to define JAVA_HOME
environment variable for the custom Maven. To ensure a system JDK usage, please set jdkPath
to ${local.env.JAVA_HOME}
.
build.mavenPhases[]
build.mavenPhases[]
build > mavenPhases
Defines the Maven phases to be executed during the Garden build step.
build.mavendPath
build.mavendPath
build > mavendPath
Defines the location of the custom executable Maven Daemon binary.
If not provided, then Maven Daemon 0.9.0 will be downloaded and used.
Note! Either jdkVersion
or jdkPath
will be used to define JAVA_HOME
environment variable for the custom Maven Daemon. To ensure a system JDK usage, please set jdkPath
to ${local.env.JAVA_HOME}
.
build.concurrentMavenBuilds
build.concurrentMavenBuilds
build > concurrentMavenBuilds
Experimental: this is an experimental feature and the API might change in the future.
[EXPERIMENTAL] Enable/disable concurrent Maven and Maven Daemon builds.
Note! Concurrent builds can be unstable. This option is disabled by default. This option must be configured for each Build action individually.
build.extraFlags[]
build.extraFlags[]
build > extraFlags
Specify extra flags to pass to maven/gradle when building the container image.
local
local
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/).
Garden will therefore not stage the build for local modules. This means that include/exclude filters and ignore files are not applied to local modules, except to calculate the module/action versions.
If you use use build.dependencies[].copy
for one or more build dependencies of this module, the copied files will be copied to the module source directory (instead of the build directory, as is the default case when local = false
).
Note: This maps to the buildAtSource
option in this module's generated Build action (if any).
description
description
A description of the module.
disabled
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.
include[]
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.
If neither include
nor exclude
is set, and the module has a Dockerfile, Garden will parse the Dockerfile and automatically set include
to match the files and folders added to the Docker image (via the COPY
and ADD
directives in the Dockerfile).
If neither include
nor exclude
is set, and the module specifies a remote image, Garden automatically sets include
to []
.
Example:
exclude[]
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 scan.exclude
field in the project config, the filters here have no effect on which files and directories are watched for changes. Use the project scan.exclude
field to affect those, if you have large directories that should not be watched for changes.
Example:
repositoryUrl
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: #<branch|tag>
Garden will import the repository source code into this module, but read the module's config from the local garden.yml file.
Example:
allowPublish
allowPublish
When false, disables pushing this module to remote registries via the publish command.
generateFiles[]
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.
generateFiles[].sourcePath
generateFiles[].sourcePath
generateFiles > sourcePath
POSIX-style filename to read the source file contents from, relative to the path of the module (or the ConfigTemplate configuration file if one is being applied). This file may contain template strings, much like any other field in the configuration.
generateFiles[].targetPath
generateFiles[].targetPath
generateFiles > targetPath
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 configuration).
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.
generateFiles[].resolveTemplates
generateFiles[].resolveTemplates
generateFiles > resolveTemplates
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.
generateFiles[].value
generateFiles[].value
generateFiles > value
The desired file contents as a string.
variables
variables
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.
varfile
varfile
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:
.yaml
/.yml
- YAML. The file must consist of a YAML document, which must be a map (dictionary). Keys may contain any value type. YAML format is used by default..env
- Standard "dotenv" format, as defined by dotenv..json
- JSON. Must contain a single JSON object (not an array).
NOTE: The default varfile format was changed to YAML in Garden v0.13, since YAML allows for definition of nested objects and arrays.
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 varfiles exist).
Example:
buildArgs
buildArgs
Specify build arguments to use when building the container image.
Note: Garden will always set a GARDEN_ACTION_VERSION
(alias GARDEN_MODULE_VERSION
) argument with the module/build version at build time.
extraFlags[]
extraFlags[]
Specify extra flags to use when building the container image. Note that arguments may not be portable across implementations.
platforms[]
platforms[]
Specify the platforms to build the image for. This is useful when building multi-platform images. The format is os/arch
, e.g. linux/amd64
, linux/arm64
, etc.
secrets
secrets
Secret values that can be mounted in the Dockerfile, but do not become part of the image filesystem or image manifest. This is useful e.g. for private registry auth tokens.
Build arguments and environment variables are inappropriate for secrets, as they persist in the final image.
The secret can later be consumed in the Dockerfile like so:
See also https://docs.docker.com/build/building/secrets/
Example:
image
image
Specify the image name for the container. Should be a valid Docker image identifier. If specified and the module does not contain a Dockerfile, this image will be used to deploy services for this module. If specified and the module does contain a Dockerfile, this identifier is used when pushing the built image.
dockerfile
dockerfile
POSIX-style name of a Dockerfile, relative to module root.
services[]
services[]
A list of services to deploy from this container module.
services[].name
services[].name
services > name
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 characters.
services[].dependencies[]
services[].dependencies[]
services > dependencies
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.
services[].disabled
services[].disabled
services > disabled
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 development.
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.
services[].command[]
services[].command[]
services > command
The command/entrypoint to run the container with.
Example:
services[].args[]
services[].args[]
services > args
The arguments (on top of the command
, i.e. entrypoint) to run the container with.
Example:
services[].env
services[].env
services > env
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.
Example:
services[].cpu
services[].cpu
services > cpu
services[].cpu.min
services[].cpu.min
The minimum amount of CPU the container needs to be available for it to be deployed, in millicpus (i.e. 1000 = 1 CPU)
services[].cpu.max
services[].cpu.max
The maximum amount of CPU the container can use, in millicpus (i.e. 1000 = 1 CPU). If set to null will result in no limit being set.
services[].memory
services[].memory
services > memory
services[].memory.min
services[].memory.min
The minimum amount of RAM the container needs to be available for it to be deployed, in megabytes (i.e. 1024 = 1 GB)
services[].memory.max
services[].memory.max
The maximum amount of RAM the container can use, in megabytes (i.e. 1024 = 1 GB) If set to null will result in no limit being set.
services[].volumes[]
services[].volumes[]
services > volumes
List of volumes that should be mounted when starting the container.
Note: If neither hostPath
nor module
is specified, an empty ephemeral volume is created and mounted when deploying the container.
services[].volumes[].name
services[].volumes[].name
The name of the allocated volume.
services[].volumes[].containerPath
services[].volumes[].containerPath
services > volumes > containerPath
The path where the volume should be mounted in the container.
services[].volumes[].hostPath
services[].volumes[].hostPath
NOTE: Usage of hostPath is generally discouraged, since it doesn't work reliably across different platforms and providers. Some providers may not support it at all.
A local path or path on the node that's running the container, to mount in the container, relative to the config source directory (or absolute).
Example:
services[].volumes[].module
services[].volumes[].module
The name of a volume module that should be mounted at containerPath
. The supported module types will depend on which provider you are using. The kubernetes
provider supports the persistentvolumeclaim module, for example.
When a module
is specified, the referenced module/volume will be automatically configured as a runtime dependency of this service, as well as a build dependency of this module.
Note: Make sure to pay attention to the supported accessModes
of the referenced volume. Unless it supports the ReadWriteMany access mode, you'll need to make sure it is not configured to be mounted by multiple services at the same time. Refer to the documentation of the module type in question to learn more.
services[].privileged
services[].privileged
services > privileged
If true, run the main container in privileged mode. Processes in privileged containers are essentially equivalent to root on the host. Defaults to false.
services[].addCapabilities[]
services[].addCapabilities[]
services > addCapabilities
POSIX capabilities to add when running the container.
services[].dropCapabilities[]
services[].dropCapabilities[]
services > dropCapabilities
POSIX capabilities to remove when running the container.
services[].tty
services[].tty
services > tty
Specify if containers in this action have TTY support enabled (which implies having stdin support enabled).
services[].deploymentStrategy
services[].deploymentStrategy
services > deploymentStrategy
Specifies the container's deployment strategy.
services[].annotations
services[].annotations
services > annotations
Annotations to attach to the service (note: May not be applicable to all providers).
When using the Kubernetes provider, these annotations are applied to both Service and Pod resources. You can generally specify the annotations intended for both Pods or Services here, and the ones that don't apply on either side will be ignored (i.e. if you put a Service annotation here, it'll also appear on Pod specs but will be safely ignored there, and vice versa).
Example:
services[].daemon
services[].daemon
services > daemon
Whether to run the service as a daemon (to ensure exactly one instance runs per node). May not be supported by all providers.
services[].sync
services[].sync
services > sync
Specifies which files or directories to sync to which paths inside the running containers of the service when it's in sync mode, and overrides for the container command and/or arguments.
Sync is enabled e.g. by setting the --sync
flag on the garden deploy
command.
See the Code Synchronization guide for more information.
services[].sync.args[]
services[].sync.args[]
Override the default container arguments when in sync mode.
services[].sync.command[]
services[].sync.command[]
Override the default container command (i.e. entrypoint) when in sync mode.
services[].sync.paths[]
services[].sync.paths[]
Specify one or more source files or directories to automatically sync with the running container.
services[].sync.paths[].source
services[].sync.paths[].source
services > sync > paths > source
Path to a local directory to be synchronized with the target. This should generally be a templated path to another action's source path (e.g. ${actions.build.my-container-image.sourcePath}
), or a relative path. If a path is hard-coded, we recommend sticking with relative paths here, and using forward slashes (/
) as a delimiter, as Windows-style paths with back slashes (\
) and absolute paths will work on some platforms, but they are not portable and will not work for users on other platforms. Defaults to the Deploy action's config's directory if no value is provided.
Example:
services[].sync.paths[].target
services[].sync.paths[].target
services > sync > paths > target
POSIX-style absolute path to sync to inside the container. The root path (i.e. "/") is not allowed.
Example:
services[].sync.paths[].exclude[]
services[].sync.paths[].exclude[]
services > sync > paths > exclude
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.
Example:
services[].sync.paths[].mode
services[].sync.paths[].mode
services > sync > paths > mode
The sync mode to use for the given paths. See the Code Synchronization guide for details.
services[].sync.paths[].defaultFileMode
services[].sync.paths[].defaultFileMode
services > sync > paths > defaultFileMode
The default permission bits, specified as an octal, to set on files at the sync target. Defaults to 0o644 (user can read/write, everyone else can read). See the Mutagen docs for more information.
services[].sync.paths[].defaultDirectoryMode
services[].sync.paths[].defaultDirectoryMode
services > sync > paths > defaultDirectoryMode
The default permission bits, specified as an octal, to set on directories at the sync target. Defaults to 0o755 (user can read/write, everyone else can read). See the Mutagen docs for more information.
services[].sync.paths[].defaultOwner
services[].sync.paths[].defaultOwner
services > sync > paths > defaultOwner
Set the default owner of files and directories at the target. Specify either an integer ID or a string name. See the Mutagen docs for more information.
services[].sync.paths[].defaultGroup
services[].sync.paths[].defaultGroup
services > sync > paths > defaultGroup
Set the default group on files and directories at the target. Specify either an integer ID or a string name. See the Mutagen docs for more information.
services[].localMode
services[].localMode
services > localMode
[EXPERIMENTAL] Configures the local application which will send and receive network requests instead of the target resource.
The target service will be replaced by a proxy container which runs an SSH server to proxy requests. Reverse port-forwarding will be automatically configured to route traffic to the local service and back.
Local mode is enabled by setting the --local
option on the garden deploy
command. Local mode always takes the precedence over sync mode if there are any conflicting service names.
Health checks are disabled for services running in local mode.
See the Local Mode guide for more information.
Note! This feature is still experimental. Some incompatible changes can be made until the first non-experimental release.
services[].localMode.ports[]
services[].localMode.ports[]
The reverse port-forwards configuration for the local application.
services[].localMode.ports[].local
services[].localMode.ports[].local
services > localMode > ports > local
The local port to be used for reverse port-forward.
services[].localMode.ports[].remote
services[].localMode.ports[].remote
services > localMode > ports > remote
The remote port to be used for reverse port-forward.
services[].localMode.command[]
services[].localMode.command[]
services > localMode > command
The command to run the local application. If not present, then the local application should be started manually.
services[].localMode.restart
services[].localMode.restart
services > localMode > restart
Specifies restarting policy for the local application. By default, the local application will be restarting infinitely with 1000ms between attempts.
services[].localMode.restart.delayMsec
services[].localMode.restart.delayMsec
services > localMode > restart > delayMsec
Delay in milliseconds between the local application restart attempts. The default value is 1000ms.
services[].localMode.restart.max
services[].localMode.restart.max
services > localMode > restart > max
Max number of the local application restarts. Unlimited by default.
services[].image
services[].image
services > image
Specify an image ID to deploy. Should be a valid Docker image identifier. Required if no build
is specified.
services[].ingresses[]
services[].ingresses[]
services > ingresses
List of ingress endpoints that the service exposes.
Example:
services[].ingresses[].annotations
services[].ingresses[].annotations
services > ingresses > annotations
Annotations to attach to the ingress (Note: May not be applicable to all providers)
Example:
services[].ingresses[].hostname
services[].ingresses[].hostname
services > ingresses > hostname
The hostname that should route to this service. Defaults to the default hostname configured in the provider configuration.
Note that if you're developing locally you may need to add this hostname to your hosts file.
services[].ingresses[].linkUrl
services[].ingresses[].linkUrl
services > ingresses > linkUrl
The link URL for the ingress to show in the console and in dashboards. Also used when calling the service with the call
command.
Use this if the actual URL is different from what's specified in the ingress, e.g. because there's a load balancer in front of the service that rewrites the paths.
Otherwise Garden will construct the link URL from the ingress spec.
services[].ingresses[].path
services[].ingresses[].path
The path which should be routed to the service.
services[].ingresses[].port
services[].ingresses[].port
The name of the container port where the specified paths should be routed.
services[].healthCheck
services[].healthCheck
services > healthCheck
Specify how the service's health should be checked after deploying.
services[].healthCheck.httpGet
services[].healthCheck.httpGet
services > healthCheck > httpGet
Set this to check the service's health by making an HTTP request.
services[].healthCheck.httpGet.path
services[].healthCheck.httpGet.path
services > healthCheck > httpGet > path
The path of the service's health check endpoint.
services[].healthCheck.httpGet.port
services[].healthCheck.httpGet.port
services > healthCheck > httpGet > port
The name of the port where the service's health check endpoint should be available.
services[].healthCheck.httpGet.scheme
services[].healthCheck.httpGet.scheme
services > healthCheck > httpGet > scheme
services[].healthCheck.command[]
services[].healthCheck.command[]
services > healthCheck > command
Set this to check the service's health by running a command in its container.
services[].healthCheck.tcpPort
services[].healthCheck.tcpPort
services > healthCheck > tcpPort
Set this to check the service's health by checking if this TCP port is accepting connections.
services[].healthCheck.readinessTimeoutSeconds
services[].healthCheck.readinessTimeoutSeconds
services > healthCheck > readinessTimeoutSeconds
The maximum number of seconds to wait until the readiness check counts as failed.
services[].healthCheck.livenessTimeoutSeconds
services[].healthCheck.livenessTimeoutSeconds
services > healthCheck > livenessTimeoutSeconds
The maximum number of seconds to wait until the liveness check counts as failed.
services[].timeout
services[].timeout
services > timeout
The maximum duration (in seconds) to wait for resources to deploy and become healthy.
services[].limits
services[].limits
services > limits
Deprecated: This field will be removed in a future release.
Specify resource limits for the service.
services[].limits.cpu
services[].limits.cpu
Deprecated: This field will be removed in a future release.
The maximum amount of CPU the service can use, in millicpus (i.e. 1000 = 1 CPU)
services[].limits.memory
services[].limits.memory
Deprecated: This field will be removed in a future release.
The maximum amount of RAM the service can use, in megabytes (i.e. 1024 = 1 GB)
services[].ports[]
services[].ports[]
services > ports
List of ports that the service container exposes.
services[].ports[].name
services[].ports[].name
The name of the port (used when referencing the port elsewhere in the service configuration).
services[].ports[].protocol
services[].ports[].protocol
The protocol of the port.
services[].ports[].containerPort
services[].ports[].containerPort
services > ports > containerPort
The port exposed on the container by the running process. This will also be the default value for servicePort
. This is the port you would expose in your Dockerfile and that your process listens on. This is commonly a non-privileged port like 8080 for security reasons. The service port maps to the container port: servicePort:80 -> containerPort:8080 -> process:8080
Example:
services[].ports[].localPort
services[].ports[].localPort
Specify a preferred local port to attach to when creating a port-forward to the service port. If this port is busy, a warning will be shown and an alternative port chosen.
Example:
services[].ports[].servicePort
services[].ports[].servicePort
services > ports > servicePort
The port exposed on the service. Defaults to containerPort
if not specified. This is the port you use when calling a service from another service within the cluster. For example, if your service name is my-service and the service port is 8090, you would call it with: http://my-service:8090/some-endpoint. It is common to use port 80, the default port number, so that you can call the service directly with http://my-service/some-endpoint. The service port maps to the container port: servicePort:80 -> containerPort:8080 -> process:8080
Example:
services[].ports[].hostPort
services[].ports[].hostPort
Deprecated: This field will be removed in a future release.
services[].ports[].nodePort
services[].ports[].nodePort
Set this to expose the service on the specified port on the host node (may not be supported by all providers). Set to true
to have the cluster pick a port automatically, which is most often advisable if the cluster is shared by multiple users. This allows you to call the service from the outside by the node's IP address and the port number set in this field.
services[].replicas
services[].replicas
services > replicas
The number of instances of the service to deploy. Defaults to 3 for environments configured with production: true
, otherwise 1. Note: This setting may be overridden or ignored in some cases. For example, when running with daemon: true
or if the provider doesn't support multiple replicas.
tests[]
tests[]
A list of tests to run in the module.
tests[].name
tests[].name
tests > name
The name of the test.
tests[].dependencies[]
tests[].dependencies[]
tests > dependencies
The names of any services that must be running, and the names of any tasks that must be executed, before the test is run.
tests[].disabled
tests[].disabled
tests > disabled
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.
tests[].timeout
tests[].timeout
tests > timeout
Maximum duration (in seconds) of the test run.
tests[].command[]
tests[].command[]
tests > command
The command/entrypoint to run the container with.
Example:
tests[].args[]
tests[].args[]
tests > args
The arguments (on top of the command
, i.e. entrypoint) to run the container with.
Example:
tests[].env
tests[].env
tests > env
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.
Example:
tests[].cpu
tests[].cpu
tests > cpu
tests[].cpu.min
tests[].cpu.min
The minimum amount of CPU the container needs to be available for it to be deployed, in millicpus (i.e. 1000 = 1 CPU)
tests[].cpu.max
tests[].cpu.max
The maximum amount of CPU the container can use, in millicpus (i.e. 1000 = 1 CPU). If set to null will result in no limit being set.
tests[].memory
tests[].memory
tests > memory
tests[].memory.min
tests[].memory.min
The minimum amount of RAM the container needs to be available for it to be deployed, in megabytes (i.e. 1024 = 1 GB)
tests[].memory.max
tests[].memory.max
The maximum amount of RAM the container can use, in megabytes (i.e. 1024 = 1 GB) If set to null will result in no limit being set.
tests[].volumes[]
tests[].volumes[]
tests > volumes
List of volumes that should be mounted when starting the container.
Note: If neither hostPath
nor module
is specified, an empty ephemeral volume is created and mounted when deploying the container.
tests[].volumes[].name
tests[].volumes[].name
The name of the allocated volume.
tests[].volumes[].containerPath
tests[].volumes[].containerPath
tests > volumes > containerPath
The path where the volume should be mounted in the container.
tests[].volumes[].hostPath
tests[].volumes[].hostPath
NOTE: Usage of hostPath is generally discouraged, since it doesn't work reliably across different platforms and providers. Some providers may not support it at all.
A local path or path on the node that's running the container, to mount in the container, relative to the config source directory (or absolute).
Example:
tests[].volumes[].module
tests[].volumes[].module
The name of a volume module that should be mounted at containerPath
. The supported module types will depend on which provider you are using. The kubernetes
provider supports the persistentvolumeclaim module, for example.
When a module
is specified, the referenced module/volume will be automatically configured as a runtime dependency of this service, as well as a build dependency of this module.
Note: Make sure to pay attention to the supported accessModes
of the referenced volume. Unless it supports the ReadWriteMany access mode, you'll need to make sure it is not configured to be mounted by multiple services at the same time. Refer to the documentation of the module type in question to learn more.
tests[].privileged
tests[].privileged
tests > privileged
If true, run the main container in privileged mode. Processes in privileged containers are essentially equivalent to root on the host. Defaults to false.
tests[].addCapabilities[]
tests[].addCapabilities[]
tests > addCapabilities
POSIX capabilities to add when running the container.
tests[].dropCapabilities[]
tests[].dropCapabilities[]
tests > dropCapabilities
POSIX capabilities to remove when running the container.
tests[].tty
tests[].tty
tests > tty
Specify if containers in this action have TTY support enabled (which implies having stdin support enabled).
tests[].deploymentStrategy
tests[].deploymentStrategy
tests > deploymentStrategy
Specifies the container's deployment strategy.
tests[].artifacts[]
tests[].artifacts[]
tests > artifacts
Specify artifacts to copy out of the container after the run. The artifacts are stored locally under the .garden/artifacts
directory.
Note: Depending on the provider, this may require the container image to include sh
tar
, in order to enable the file transfer.
Example:
tests[].artifacts[].source
tests[].artifacts[].source
A POSIX-style path or glob to copy. Must be an absolute path. May contain wildcards.
Example:
tests[].artifacts[].target
tests[].artifacts[].target
A POSIX-style path to copy the artifacts to, relative to the project artifacts directory at .garden/artifacts
.
Example:
tests[].image
tests[].image
tests > image
Specify an image ID to deploy. Should be a valid Docker image identifier. Required if no build
is specified.
tasks[]
tasks[]
A list of tasks that can be run from this container module. These can be used as dependencies for services (executed before the service is deployed) or for other tasks.
tasks[].name
tasks[].name
tasks > name
The name of the task.
tasks[].description
tasks[].description
tasks > description
A description of the task.
tasks[].dependencies[]
tasks[].dependencies[]
tasks > dependencies
The names of any tasks that must be executed, and the names of any services that must be running, before this task is executed.
tasks[].disabled
tasks[].disabled
tasks > disabled
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 development.
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.
tasks[].timeout
tasks[].timeout
tasks > timeout
Maximum duration (in seconds) of the task's execution.
tasks[].command[]
tasks[].command[]
tasks > command
The command/entrypoint to run the container with.
Example:
tasks[].args[]
tasks[].args[]
tasks > args
The arguments (on top of the command
, i.e. entrypoint) to run the container with.
Example:
tasks[].env
tasks[].env
tasks > env
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.
Example:
tasks[].cpu
tasks[].cpu
tasks > cpu
tasks[].cpu.min
tasks[].cpu.min
The minimum amount of CPU the container needs to be available for it to be deployed, in millicpus (i.e. 1000 = 1 CPU)
tasks[].cpu.max
tasks[].cpu.max
The maximum amount of CPU the container can use, in millicpus (i.e. 1000 = 1 CPU). If set to null will result in no limit being set.
tasks[].memory
tasks[].memory
tasks > memory
tasks[].memory.min
tasks[].memory.min
The minimum amount of RAM the container needs to be available for it to be deployed, in megabytes (i.e. 1024 = 1 GB)
tasks[].memory.max
tasks[].memory.max
The maximum amount of RAM the container can use, in megabytes (i.e. 1024 = 1 GB) If set to null will result in no limit being set.
tasks[].volumes[]
tasks[].volumes[]
tasks > volumes
List of volumes that should be mounted when starting the container.
Note: If neither hostPath
nor module
is specified, an empty ephemeral volume is created and mounted when deploying the container.
tasks[].volumes[].name
tasks[].volumes[].name
The name of the allocated volume.
tasks[].volumes[].containerPath
tasks[].volumes[].containerPath
tasks > volumes > containerPath
The path where the volume should be mounted in the container.
tasks[].volumes[].hostPath
tasks[].volumes[].hostPath
NOTE: Usage of hostPath is generally discouraged, since it doesn't work reliably across different platforms and providers. Some providers may not support it at all.
A local path or path on the node that's running the container, to mount in the container, relative to the config source directory (or absolute).
Example:
tasks[].volumes[].module
tasks[].volumes[].module
The name of a volume module that should be mounted at containerPath
. The supported module types will depend on which provider you are using. The kubernetes
provider supports the persistentvolumeclaim module, for example.
When a module
is specified, the referenced module/volume will be automatically configured as a runtime dependency of this service, as well as a build dependency of this module.
Note: Make sure to pay attention to the supported accessModes
of the referenced volume. Unless it supports the ReadWriteMany access mode, you'll need to make sure it is not configured to be mounted by multiple services at the same time. Refer to the documentation of the module type in question to learn more.
tasks[].privileged
tasks[].privileged
tasks > privileged
If true, run the main container in privileged mode. Processes in privileged containers are essentially equivalent to root on the host. Defaults to false.
tasks[].addCapabilities[]
tasks[].addCapabilities[]
tasks > addCapabilities
POSIX capabilities to add when running the container.
tasks[].dropCapabilities[]
tasks[].dropCapabilities[]
tasks > dropCapabilities
POSIX capabilities to remove when running the container.
tasks[].tty
tasks[].tty
tasks > tty
Specify if containers in this action have TTY support enabled (which implies having stdin support enabled).
tasks[].deploymentStrategy
tasks[].deploymentStrategy
tasks > deploymentStrategy
Specifies the container's deployment strategy.
tasks[].artifacts[]
tasks[].artifacts[]
tasks > artifacts
Specify artifacts to copy out of the container after the run. The artifacts are stored locally under the .garden/artifacts
directory.
Note: Depending on the provider, this may require the container image to include sh
tar
, in order to enable the file transfer.
Example:
tasks[].artifacts[].source
tasks[].artifacts[].source
A POSIX-style path or glob to copy. Must be an absolute path. May contain wildcards.
Example:
tasks[].artifacts[].target
tasks[].artifacts[].target
A POSIX-style path to copy the artifacts to, relative to the project artifacts directory at .garden/artifacts
.
Example:
tasks[].image
tasks[].image
tasks > image
Specify an image ID to deploy. Should be a valid Docker image identifier. Required if no build
is specified.
tasks[].cacheResult
tasks[].cacheResult
tasks > cacheResult
Set to false if you don't want the Runs's result to be cached. Use this if the Run needs to be run any time your project (or one or more of the Run's dependants) is deployed. Otherwise the Run is only re-run when its version changes, or when you run garden run
.
Outputs
Module Outputs
The following keys are available via the ${modules.<module-name>}
template string key for jib-container
modules.
${modules.<module-name>.buildPath}
${modules.<module-name>.buildPath}
The build path of the module.
Example:
${modules.<module-name>.name}
${modules.<module-name>.name}
The name of the module.
${modules.<module-name>.path}
${modules.<module-name>.path}
The source path of the module.
Example:
${modules.<module-name>.var.*}
${modules.<module-name>.var.*}
A map of all variables defined in the module.
${modules.<module-name>.var.<variable-name>}
${modules.<module-name>.var.<variable-name>}
${modules.<module-name>.version}
${modules.<module-name>.version}
The current version of the module.
Example:
Service Outputs
The following keys are available via the ${runtime.services.<service-name>}
template string key for jib-container
module services. Note that these are only resolved when deploying/running dependants of the service, so they are not usable for every field.
${runtime.services.<service-name>.version}
${runtime.services.<service-name>.version}
The current version of the service.
Example:
Task Outputs
The following keys are available via the ${runtime.tasks.<task-name>}
template string key for jib-container
module tasks. Note that these are only resolved when deploying/running dependants of the task, so they are not usable for every field.
${runtime.tasks.<task-name>.version}
${runtime.tasks.<task-name>.version}
The current version of the task.
Example:
Last updated