maven-container

Description

DEPRECATED. Please use the jib-container module type instead.
A specialized version of the container module type that has special semantics for JAR files built with Maven.
Rather than build the JAR inside the container (or in a multi-stage build) this plugin runs mvn package ahead of building the container, which tends to be much more performant, especially when building locally with a warm artifact cache.
A default Dockerfile is also provided for convenience, but you may override it by including one in the module directory.
To use it, make sure to add the maven-container provider to your project configuration. The provider will automatically fetch and cache Maven and the appropriate OpenJDK version ahead of building.
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.
maven-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.
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
# Maximum time in seconds to wait for build to finish.
29
timeout: 1200
30
​
31
# For multi-stage Dockerfiles, specify which image to build (see
32
# https://docs.docker.com/engine/reference/commandline/build/#specifying-target-build-stage---target for details).
33
targetImage:
34
​
35
# A description of the module.
36
description:
37
​
38
# Set this to `true` to disable the module. You can use this with conditional template strings to disable modules
39
# based on, for example, the current environment or other variables (e.g. `disabled: \${environment.name == "prod"}`).
40
# This can be handy when you only need certain modules for specific environments, e.g. only for development.
41
#
42
# Disabling a module means that any services, tasks and tests contained in it will not be deployed or run. It also
43
# means that the module is not built _unless_ it is declared as a build dependency by another enabled module (in which
44
# case building this module is necessary for the dependant to be built).
45
#
46
# If you disable the module, and its services, tasks or tests are referenced as _runtime_ dependencies, Garden will
47
# automatically ignore those dependency declarations. Note however that template strings referencing the module's
48
# service or task outputs (i.e. runtime outputs) will fail to resolve when the module is disabled, so you need to make
49
# sure to provide alternate values for those if you're using them, using conditional expressions.
50
disabled: false
51
​
52
# Specify a list of POSIX-style paths or globs that should be regarded as the source files for this module. Files that
53
# do *not* match these paths or globs are excluded when computing the version of the module, when responding to
54
# filesystem watch events, and when staging builds.
55
#
56
# Note that you can also _exclude_ files using the `exclude` field or by placing `.gardenignore` files in your source
57
# tree, which use the same format as `.gitignore` files. See the [Configuration Files
58
# guide](https://docs.garden.io/using-garden/configuration-overview#including-excluding-files-and-directories) for
59
# details.
60
#
61
# Also note that specifying an empty list here means _no sources_ should be included.
62
include:
63
​
64
# Specify a list of POSIX-style paths or glob patterns that should be excluded from the module. Files that match these
65
# paths or globs are excluded when computing the version of the module, when responding to filesystem watch events,
66
# and when staging builds.
67
#
68
# Note that you can also explicitly _include_ files using the `include` field. If you also specify the `include`
69
# field, the files/patterns specified here are filtered from the files matched by `include`. See the [Configuration
70
# Files guide](https://docs.garden.io/using-garden/configuration-overview#including-excluding-files-and-directories)
71
# for details.
72
#
73
# Unlike the `modules.exclude` field in the project config, the filters here have _no effect_ on which files and
74
# directories are watched for changes. Use the project `modules.exclude` field to affect those, if you have large
75
# directories that should not be watched for changes.
76
exclude:
77
​
78
# A remote repository URL. Currently only supports git servers. Must contain a hash suffix pointing to a specific
79
# branch or tag, with the format: <git remote url>#<branch|tag>
80
#
81
# Garden will import the repository source code into this module, but read the module's config from the local
82
# garden.yml file.
83
repositoryUrl:
84
​
85
# When false, disables pushing this module to remote registries.
86
allowPublish: true
87
​
88
# A list of files to write to the module directory when resolving this module. This is useful to automatically
89
# generate (and template) any supporting files needed for the module.
90
generateFiles:
91
- # POSIX-style filename to read the source file contents from, relative to the path of the module (or the
92
# ModuleTemplate configuration file if one is being applied).
93
# This file may contain template strings, much like any other field in the configuration.
94
sourcePath:
95
​
96
# POSIX-style filename to write the resolved file contents to, relative to the path of the module source directory
97
# (for remote modules this means the root of the module repository, otherwise the directory of the module
98
# configuration).
99
#
100
# Note that any existing file with the same name will be overwritten. If the path contains one or more
101
# directories, they will be automatically created if missing.
102
targetPath:
103
​
104
# By default, Garden will attempt to resolve any Garden template strings in source files. Set this to false to
105
# skip resolving template strings. Note that this does not apply when setting the `value` field, since that's
106
# resolved earlier when parsing the configuration.
107
resolveTemplates: true
108
​
109
# The desired file contents as a string.
110
value:
111
​
112
# A map of variables scoped to this particular module. These are resolved before any other parts of the module
113
# configuration and take precedence over project-scoped variables. They may reference project-scoped variables, and
114
# generally use any template strings normally allowed when resolving modules.
115
variables:
116
​
117
# Specify a path (relative to the module root) to a file containing variables, that we apply on top of the
118
# module-level `variables` field.
119
#
120
# The format of the files is determined by the configured file's extension:
121
#
122
# * `.env` - Standard "dotenv" format, as defined by [dotenv](https://github.com/motdotla/dotenv#rules).
123
# * `.yaml`/`.yml` - YAML. The file must consist of a YAML document, which must be a map (dictionary). Keys may
124
# contain any value type.
125
# * `.json` - JSON. Must contain a single JSON _object_ (not an array).
126
#
127
# _NOTE: The default varfile format will change to YAML in Garden v0.13, since YAML allows for definition of nested
128
# objects and arrays._
129
#
130
# To use different module-level varfiles in different environments, you can template in the environment name
131
# to the varfile name, e.g. `varfile: "my-module.\$\{environment.name\}.env` (this assumes that the corresponding
132
# varfiles exist).
133
varfile:
134
​
135
# Specify build arguments to use when building the container image.
136
#
137
# Note: Garden will always set a `GARDEN_MODULE_VERSION` argument with the module version at build time.
138
buildArgs: {}
139
​
140
# Specify extra flags to use when building the container image. Note that arguments may not be portable across
141
# implementations.
142
extraFlags:
143
​
144
# Specify the image name for the container. Should be a valid Docker image identifier. If specified and the module
145
# does not contain a Dockerfile, this image will be used to deploy services for this module. If specified and the
146
# module does contain a Dockerfile, this identifier is used when pushing the built image.
147
image:
148
​
149
# Specifies which files or directories to sync to which paths inside the running containers of hot reload-enabled
150
# services when those files or directories are modified. Applies to this module's services, and to services with this
151
# module as their `sourceModule`.
152
hotReload:
153
# Specify one or more source files or directories to automatically sync into the running container.
154
sync:
155
- # POSIX-style path of the directory to sync to the target, relative to the module's top-level directory. Must be
156
# a relative path. Defaults to the module's top-level directory if no value is provided.
157
source: .
158
​
159
# POSIX-style absolute path to sync the directory to inside the container. The root path (i.e. "/") is not
160
# allowed.
161
target:
162
​
163
# An optional command to run inside the container after syncing.
164
postSyncCommand:
165
​
166
# POSIX-style name of Dockerfile, relative to module root.
167
dockerfile:
168
​
169
# A list of services to deploy from this container module.
170
services:
171
- # Valid RFC1035/RFC1123 (DNS) label (may contain lowercase letters, numbers and dashes, must start with a letter,
172
# and cannot end with a dash), cannot contain consecutive dashes or start with `garden`, or be longer than 63
173
# characters.
174
name:
175
​
176
# The names of any services that this service depends on at runtime, and the names of any tasks that should be
177
# executed before this service is deployed.
178
dependencies: []
179
​
180
# Set this to `true` to disable the service. You can use this with conditional template strings to enable/disable
181
# services based on, for example, the current environment or other variables (e.g. `enabled: \${environment.name
182
# != "prod"}`). This can be handy when you only need certain services for specific environments, e.g. only for
183
# development.
184
#
185
# Disabling a service means that it will not be deployed, and will also be ignored if it is declared as a runtime
186
# dependency for another service, test or task.
187
#
188
# Note however that template strings referencing the service's outputs (i.e. runtime outputs) will fail to resolve
189
# when the service is disabled, so you need to make sure to provide alternate values for those if you're using
190
# them, using conditional expressions.
191
disabled: false
192
​
193
# Annotations to attach to the service _(note: May not be applicable to all providers)_.
194
#
195
# When using the Kubernetes provider, these annotations are applied to both Service and Pod resources. You can
196
# generally specify the annotations intended for both Pods or Services here, and the ones that don't apply on
197
# either side will be ignored (i.e. if you put a Service annotation here, it'll also appear on Pod specs but will
198
# be safely ignored there, and vice versa).
199
annotations: {}
200
​
201
# The command/entrypoint to run the container with when starting the service.
202
command:
203
​
204
# The arguments to run the container with when starting the service.
205
args:
206
​
207
# Whether to run the service as a daemon (to ensure exactly one instance runs per node). May not be supported by
208
# all providers.
209
daemon: false
210
​
211
# Specifies which files or directories to sync to which paths inside the running containers of the service when
212
# it's in dev mode, and overrides for the container command and/or arguments.
213
#
214
# Dev mode is enabled when running the `garden dev` command, and by setting the `--dev` flag on the `garden
215
# deploy` command.
216
#
217
# See the [Code Synchronization guide](https://docs.garden.io/guides/code-synchronization-dev-mode) for more
218
# information.
219
devMode:
220
# Override the default container arguments when in dev mode.
221
args:
222
​
223
# Override the default container command (i.e. entrypoint) when in dev mode.
224
command:
225
​
226
# Specify one or more source files or directories to automatically sync with the running container.
227
sync:
228
- # POSIX-style path of the directory to sync to the target, relative to the module's top-level directory.
229
# Must be a relative path. Defaults to the module's top-level directory if no value is provided.
230
source: .
231
​
232
# POSIX-style absolute path to sync the directory to inside the container. The root path (i.e. "/") is not
233
# allowed.
234
target:
235
​
236
# Specify a list of POSIX-style paths or glob patterns that should be excluded from the sync.
237
#
238
# `.git` directories and `.garden` directories are always ignored.
239
exclude:
240
​
241
# The sync mode to use for the given paths. See the [Dev Mode
242
# guide](https://docs.garden.io/guides/code-synchronization-dev-mode) for details.
243
mode: one-way-safe
244
​
245
# The default permission bits, specified as an octal, to set on files at the sync target. Defaults to 0600
246
# (user read/write). See the [Mutagen
247
# docs](https://mutagen.io/documentation/synchronization/permissions#permissions) for more information.
248
defaultFileMode:
249
​
250
# The default permission bits, specified as an octal, to set on directories at the sync target. Defaults to
251
# 0700 (user read/write). See the [Mutagen
252
# docs](https://mutagen.io/documentation/synchronization/permissions#permissions) for more information.
253
defaultDirectoryMode:
254
​
255
# Set the default owner of files and directories at the target. Specify either an integer ID or a string
256
# name. See the [Mutagen
257
# docs](https://mutagen.io/documentation/synchronization/permissions#owners-and-groups) for more
258
# information.
259
defaultOwner:
260
​
261
# Set the default group on files and directories at the target. Specify either an integer ID or a string
262
# name. See the [Mutagen
263
# docs](https://mutagen.io/documentation/synchronization/permissions#owners-and-groups) for more
264
# information.
265
defaultGroup:
266
​
267
# List of ingress endpoints that the service exposes.
268
ingresses:
269
- # Annotations to attach to the ingress (Note: May not be applicable to all providers)
270
annotations: {}
271
​
272
# The hostname that should route to this service. Defaults to the default hostname configured in the provider
273
# configuration.
274
#
275
# Note that if you're developing locally you may need to add this hostname to your hosts file.
276
hostname:
277
​
278
# The link URL for the ingress to show in the console and on the dashboard. Also used when calling the service
279
# with the `call` command.
280
#
281
# Use this if the actual URL is different from what's specified in the ingress, e.g. because there's a load
282
# balancer in front of the service that rewrites the paths.
283
#
284
# Otherwise Garden will construct the link URL from the ingress spec.
285
linkUrl:
286
​
287
# The path which should be routed to the service.
288
path: /
289
​
290
# The name of the container port where the specified paths should be routed.
291
port:
292
​
293
# Key/value map of environment variables. Keys must be valid POSIX environment variable names (must not start with
294
# `GARDEN`) and values must be primitives or references to secrets.
295
env: {}
296
​
297
# Specify how the service's health should be checked after deploying.
298
healthCheck:
299
# Set this to check the service's health by making an HTTP request.
300
httpGet:
301
# The path of the service's health check endpoint.
302
path:
303
​
304
# The name of the port where the service's health check endpoint should be available.
305
port:
306
​
307
scheme: HTTP
308
​
309
# Set this to check the service's health by running a command in its container.
310
command:
311
​
312
# Set this to check the service's health by checking if this TCP port is accepting connections.
313
tcpPort:
314
​
315
# The maximum number of seconds to wait until the readiness check counts as failed.
316
readinessTimeoutSeconds: 3
317
​
318
# The maximum number of seconds to wait until the liveness check counts as failed.
319
livenessTimeoutSeconds: 3
320
​
321
# If this module uses the `hotReload` field, the container will be run with this command/entrypoint when the
322
# service is deployed with hot reloading enabled.
323
hotReloadCommand:
324
​
325
# If this module uses the `hotReload` field, the container will be run with these arguments when the service is
326
# deployed with hot reloading enabled.
327
hotReloadArgs:
328
​
329
# The maximum duration (in seconds) to wait for resources to deploy and become healthy.
330
timeout: 300
331
​
332
cpu:
333
# The minimum amount of CPU the service needs to be available for it to be deployed, in millicpus (i.e. 1000 = 1
334
# CPU)
335
min: 10
336
​
337
# The maximum amount of CPU the service can use, in millicpus (i.e. 1000 = 1 CPU)
338
max: 1000
339
​
340
memory:
341
# The minimum amount of RAM the service needs to be available for it to be deployed, in megabytes (i.e. 1024 = 1
342
# GB)
343
min: 90
344
​
345
# The maximum amount of RAM the service can use, in megabytes (i.e. 1024 = 1 GB)
346
max: 90
347
​
348
# List of ports that the service container exposes.
349
ports:
350
- # The name of the port (used when referencing the port elsewhere in the service configuration).
351
name:
352
​
353
# The protocol of the port.
354
protocol: TCP
355
​
356
# The port exposed on the container by the running process. This will also be the default value for
357
# `servicePort`.
358
# This is the port you would expose in your Dockerfile and that your process listens on. This is commonly a
359
# non-priviledged port like 8080 for security reasons.
360
# The service port maps to the container port:
361
# `servicePort:80 -> containerPort:8080 -> process:8080`
362
containerPort:
363
​
364
# Specify a preferred local port to attach to when creating a port-forward to the service port. If this port
365
# is
366
# busy, a warning will be shown and an alternative port chosen.
367
localPort:
368
​
369
# The port exposed on the service. Defaults to `containerPort` if not specified.
370
# This is the port you use when calling a service from another service within the cluster. For example, if
371
# your service name is my-service and the service port is 8090, you would call it with:
372
# http://my-service:8090/some-endpoint.
373
# It is common to use port 80, the default port number, so that you can call the service directly with
374
# http://my-service/some-endpoint.
375
# The service port maps to the container port:
376
# `servicePort:80 -> containerPort:8080 -> process:8080`
377
servicePort:
378
​
379
# Set this to expose the service on the specified port on the host node (may not be supported by all
380
# providers). Set to `true` to have the cluster pick a port automatically, which is most often advisable if
381
# the cluster is shared by multiple users.
382
# This allows you to call the service from the outside by the node's IP address and the port number set in
383
# this field.
384
nodePort:
385
​
386
# The number of instances of the service to deploy. Defaults to 3 for environments configured with `production:
387
# true`, otherwise 1.
388
# Note: This setting may be overridden or ignored in some cases. For example, when running with `daemon: true`,
389
# with hot-reloading enabled, or if the provider doesn't support multiple replicas.
390
replicas:
391
​
392
# List of volumes that should be mounted when deploying the service.
393
#
394
# Note: If neither `hostPath` nor `module` is specified, an empty ephemeral volume is created and mounted when
395
# deploying the container.
396
volumes:
397
- # The name of the allocated volume.
398
name:
399
​
400
# The path where the volume should be mounted in the container.
401
containerPath:
402
​
403
# _NOTE: Usage of hostPath is generally discouraged, since it doesn't work reliably across different platforms
404
# and providers. Some providers may not support it at all._
405
#
406
# A local path or path on the node that's running the container, to mount in the container, relative to the
407
# module source path (or absolute).
408
hostPath:
409
​
410
# The name of a _volume module_ that should be mounted at `containerPath`. The supported module types will
411
# depend on which provider you are using. The `kubernetes` provider supports the [persistentvolumeclaim
412
# module](./persistentvolumeclaim.md), for example.
413
#
414
# When a `module` is specified, the referenced module/volume will be automatically configured as a runtime
415
# dependency of this service, as well as a build dependency of this module.
416
#
417
# Note: Make sure to pay attention to the supported `accessModes` of the referenced volume. Unless it supports
418
# the ReadWriteMany access mode, you'll need to make sure it is not configured to be mounted by multiple
419
# services at the same time. Refer to the documentation of the module type in question to learn more.
420
module:
421
​
422
# If true, run the service's main container in privileged mode. Processes in privileged containers are essentially
423
# equivalent to root on the host. Defaults to false.
424
privileged:
425
​
426
# Specify if containers in this module have TTY support enabled (which implies having stdin support enabled).
427
tty: false
428
​
429
# POSIX capabilities to add to the running service's main container.
430
addCapabilities:
431
​
432
# POSIX capabilities to remove from the running service's main container.
433
dropCapabilities:
434
​
435
# A list of tests to run in the module.
436
tests:
437
- # The name of the test.
438
name:
439
​
440
# The names of any services that must be running, and the names of any tasks that must be executed, before the
441
# test is run.
442
dependencies: []
443
​
444
# Set this to `true` to disable the test. You can use this with conditional template strings to
445
# enable/disable tests based on, for example, the current environment or other variables (e.g.
446
# `enabled: \${environment.name != "prod"}`). This is handy when you only want certain tests to run in
447
# specific environments, e.g. only during CI.
448
disabled: false
449
​
450
# Maximum duration (in seconds) of the test run.
451
timeout: null
452
​
453
# The arguments used to run the test inside the container.
454
args:
455
​
456
# Specify artifacts to copy out of the container after the run. The artifacts are stored locally under the
457
# `.garden/artifacts` directory.
458
#
459
# Note: Depending on the provider, this may require the container image to include `sh` `tar`, in order to enable
460
# the file transfer.
461
artifacts:
462
- # A POSIX-style path or glob to copy. Must be an absolute path. May contain wildcards.
463
source:
464
​
465
# A POSIX-style path to copy the artifacts to, relative to the project artifacts directory at
466
# `.garden/artifacts`.
467
target: .
468
​
469
# The command/entrypoint used to run the test inside the container.
470
command:
471
​
472
# Key/value map of environment variables. Keys must be valid POSIX environment variable names (must not start with
473
# `GARDEN`) and values must be primitives or references to secrets.
474
env: {}
475
​
476
cpu:
477
# The minimum amount of CPU the test needs to be available for it to be deployed, in millicpus (i.e. 1000 = 1
478
# CPU)
479
min: 10
480
​
481
# The maximum amount of CPU the test can use, in millicpus (i.e. 1000 = 1 CPU)
482
max: 1000
483
​
484
memory:
485
# The minimum amount of RAM the test needs to be available for it to be deployed, in megabytes (i.e. 1024 = 1
486
# GB)
487
min: 90
488
​
489
# The maximum amount of RAM the test can use, in megabytes (i.e. 1024 = 1 GB)
490
max: 90
491
​
492
# List of volumes that should be mounted when deploying the test.
493
#
494
# Note: If neither `hostPath` nor `module` is specified, an empty ephemeral volume is created and mounted when
495
# deploying the container.
496
volumes:
497
- # The name of the allocated volume.
498
name:
499
​
500
# The path where the volume should be mounted in the container.
501
containerPath:
502
​
503
# _NOTE: Usage of hostPath is generally discouraged, since it doesn't work reliably across different platforms
504
# and providers. Some providers may not support it at all._
505
#
506
# A local path or path on the node that's running the container, to mount in the container, relative to the
507
# module source path (or absolute).
508
hostPath:
509
​
510
# The name of a _volume module_ that should be mounted at `containerPath`. The supported module types will
511
# depend on which provider you are using. The `kubernetes` provider supports the [persistentvolumeclaim
512
# module](./persistentvolumeclaim.md), for example.
513
#
514
# When a `module` is specified, the referenced module/volume will be automatically configured as a runtime
515
# dependency of this service, as well as a build dependency of this module.
516
#
517
# Note: Make sure to pay attention to the supported `accessModes` of the referenced volume. Unless it supports
518
# the ReadWriteMany access mode, you'll need to make sure it is not configured to be mounted by multiple
519
# services at the same time. Refer to the documentation of the module type in question to learn more.
520
module:
521
​
522
# If true, run the test's main container in privileged mode. Processes in privileged containers are essentially
523
# equivalent to root on the host. Defaults to false.
524
privileged:
525
​
526
# POSIX capabilities to add to the running test's main container.
527
addCapabilities:
528
​
529
# POSIX capabilities to remove from the running test's main container.
530
dropCapabilities:
531
​
532
# A list of tasks that can be run from this container module. These can be used as dependencies for services (executed
533
# before the service is deployed) or for other tasks.
534
tasks:
535
- # The name of the task.
536
name:
537
​
538
# A description of the task.
539
description:
540
​
541
# The names of any tasks that must be executed, and the names of any services that must be running, before this
542
# task is executed.
543
dependencies: []
544
​
545
# Set this to `true` to disable the task. You can use this with conditional template strings to enable/disable
546
# tasks based on, for example, the current environment or other variables (e.g. `enabled: \${environment.name !=
547
# "prod"}`). This can be handy when you only want certain tasks to run in specific environments, e.g. only for
548
# development.
549
#
550
# Disabling a task means that it will not be run, and will also be ignored if it is declared as a runtime
551
# dependency for another service, test or task.
552
#
553
# Note however that template strings referencing the task's outputs (i.e. runtime outputs) will fail to resolve
554
# when the task is disabled, so you need to make sure to provide alternate values for those if you're using them,
555
# using conditional expressions.
556
disabled: false
557
​
558
# Maximum duration (in seconds) of the task's execution.
559
timeout: null
560
​
561
# The arguments used to run the task inside the container.
562
args:
563
​
564
# Specify artifacts to copy out of the container after the run. The artifacts are stored locally under the
565
# `.garden/artifacts` directory.
566
#
567
# Note: Depending on the provider, this may require the container image to include `sh` `tar`, in order to enable
568
# the file transfer.
569
artifacts:
570
- # A POSIX-style path or glob to copy. Must be an absolute path. May contain wildcards.
571
source:
572
​
573
# A POSIX-style path to copy the artifacts to, relative to the project artifacts directory at
574
# `.garden/artifacts`.
575
target: .
576
​
577
# 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
578
# your project (or one or more of the task's dependants) is deployed. Otherwise the task is only re-run when its
579
# version changes (i.e. the module or one of its dependencies is modified), or when you run `garden run task`.
580
cacheResult: true
581
​
582
# The command/entrypoint used to run the task inside the container.
583
command:
584
​
585
# Key/value map of environment variables. Keys must be valid POSIX environment variable names (must not start with
586
# `GARDEN`) and values must be primitives or references to secrets.
587
env: {}
588
​
589
cpu:
590
# The minimum amount of CPU the task needs to be available for it to be deployed, in millicpus (i.e. 1000 = 1
591
# CPU)
592
min: 10
593
​
594
# The maximum amount of CPU the task can use, in millicpus (i.e. 1000 = 1 CPU)
595
max: 1000
596
​
597
memory:
598
# The minimum amount of RAM the task needs to be available for it to be deployed, in megabytes (i.e. 1024 = 1
599
# GB)
600
min: 90
601
​
602
# The maximum amount of RAM the task can use, in megabytes (i.e. 1024 = 1 GB)
603
max: 90
604
​
605
# List of volumes that should be mounted when deploying the task.
606
#
607
# Note: If neither `hostPath` nor `module` is specified, an empty ephemeral volume is created and mounted when
608
# deploying the container.
609
volumes:
610
- # The name of the allocated volume.
611
name:
612
​
613
# The path where the volume should be mounted in the container.
614
containerPath:
615
​
616
# _NOTE: Usage of hostPath is generally discouraged, since it doesn't work reliably across different platforms
617
# and providers. Some providers may not support it at all._
618
#
619
# A local path or path on the node that's running the container, to mount in the container, relative to the
620
# module source path (or absolute).
621
hostPath:
622
​
623
# The name of a _volume module_ that should be mounted at `containerPath`. The supported module types will
624
# depend on which provider you are using. The `kubernetes` provider supports the [persistentvolumeclaim
625
# module](./persistentvolumeclaim.md), for example.
626
#
627
# When a `module` is specified, the referenced module/volume will be automatically configured as a runtime
628
# dependency of this service, as well as a build dependency of this module.
629
#
630
# Note: Make sure to pay attention to the supported `accessModes` of the referenced volume. Unless it supports
631
# the ReadWriteMany access mode, you'll need to make sure it is not configured to be mounted by multiple
632
# services at the same time. Refer to the documentation of the module type in question to learn more.
633
module:
634
​
635
# If true, run the task's main container in privileged mode. Processes in privileged containers are essentially
636
# equivalent to root on the host. Defaults to false.
637
privileged:
638
​
639
# POSIX capabilities to add to the running task's main container.
640
addCapabilities:
641
​
642
# POSIX capabilities to remove from the running task's main container.
643
dropCapabilities:
644
​
645
# Set this to override the default OpenJDK container image version. Make sure the image version matches the
646
# configured `jdkVersion`. Ignored if you provide your own Dockerfile.
647
imageVersion:
648
​
649
# POSIX-style path to the packaged JAR artifact, relative to the module directory.
650
jarPath:
651
​
652
# The JDK version to use.
653
jdkVersion: 8
654
​
655
# Options to add to the `mvn package` command when building.
656
mvnOpts: []
657
​
658
# Use the default Dockerfile provided with this module. If set to `false` and no Dockerfile is found, Garden will
659
# fallback to using the `image` field.
660
useDefaultDockerfile: true
Copied!

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

build.timeout

​build > timeout
Maximum time in seconds to wait for build to finish.
Type
Default
Required
number
1200
No

build.targetImage

​build > targetImage
For multi-stage Dockerfiles, specify which image to build (see https://docs.docker.com/engine/reference/commandline/build/#specifying-target-build-stage---target for details).
Type
Required
string
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: #<branch|tag>
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`
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
Default
Required
array[object]
[]
No

generateFiles[].sourcePath

​generateFiles > sourcePath
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.
Type
Required
posixPath
No

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.
Type
Required
posixPath
Yes

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.
Type
Default
Required
boolean
true
No

generateFiles[].value

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

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

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:
  • .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.
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).
Type
Required
posixPath
No
Example:
1
varfile: "my-module.env"
Copied!

buildArgs

Specify build arguments to use when building the container image.
Note: Garden will always set a GARDEN_MODULE_VERSION argument with the module version at build time.
Type
Default
Required
object
{}
No

extraFlags[]

Specify extra flags to use when building the container image. Note that arguments may not be portable across implementations.
Type
Required
array[string]
No

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.
Type
Required
string
No

hotReload

Specifies which files or directories to sync to which paths inside the running containers of hot reload-enabled services when those files or directories are modified. Applies to this module's services, and to services with this module as their sourceModule.
Type
Required
object
No

hotReload.sync[]

​hotReload > sync
Specify one or more source files or directories to automatically sync into the running container.
Type
Required
array[object]
Yes

hotReload.sync[].source

​hotReload > sync > source
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.
Type
Default
Required
posixPath
"."
No
Example:
1
hotReload:
2
...
3
sync:
4
- source: "src"
Copied!

hotReload.sync[].target

​hotReload > sync > target
POSIX-style absolute path to sync the directory to inside the container. The root path (i.e. "/") is not allowed.
Type
Required
posixPath
Yes
Example:
1
hotReload:
2
...
3
sync:
4
- target: "/app/src"
Copied!

hotReload.postSyncCommand[]

​hotReload > postSyncCommand
An optional command to run inside the container after syncing.
Type
Required
array[string]
No
Example:
1
hotReload:
2
...
3
postSyncCommand:
4
- rebuild-static-assets.sh
Copied!

dockerfile

POSIX-style name of Dockerfile, relative to module root.
Type
Required
posixPath
No

services[]

A list of services to deploy from this container module.
Type
Default
Required
array[object]
[]
No

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.
Type
Required
string
Yes

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

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.
Type
Default
Required
boolean
false
No

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).
Type
Default
Required
object
{}
No
Example:
1
services:
2
- annotations:
3
nginx.ingress.kubernetes.io/proxy-body-size: '0'
Copied!

services[].command[]

​services > command
The command/entrypoint to run the container with when starting the service.
Type
Required
array[string]
No
Example:
1
services:
2
- command:
3
- /bin/sh
4
- '-c'
Copied!

services[].args[]

​services > args
The arguments to run the container with when starting the service.
Type