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](https://docs.garden.io/reference/module-types/persistentvolumeclaim), 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
# POSIX capabilities to add to the running service's main container.
427
addCapabilities:
428
​
429
# POSIX capabilities to remove from the running service's main container.
430
dropCapabilities:
431
​
432
# A list of tests to run in the module.
433
tests:
434
- # The name of the test.
435
name:
436
​
437
# The names of any services that must be running, and the names of any tasks that must be executed, before the
438
# test is run.
439
dependencies: []
440
​
441
# Set this to `true` to disable the test. You can use this with conditional template strings to
442
# enable/disable tests based on, for example, the current environment or other variables (e.g.
443
# `enabled: \${environment.name != "prod"}`). This is handy when you only want certain tests to run in
444
# specific environments, e.g. only during CI.
445
disabled: false
446
​
447
# Maximum duration (in seconds) of the test run.
448
timeout: null
449
​
450
# The arguments used to run the test inside the container.
451
args:
452
​
453
# Specify artifacts to copy out of the container after the run. The artifacts are stored locally under the
454
# `.garden/artifacts` directory.
455
#
456
# Note: Depending on the provider, this may require the container image to include `sh` `tar`, in order to enable
457
# the file transfer.
458
artifacts:
459
- # A POSIX-style path or glob to copy. Must be an absolute path. May contain wildcards.
460
source:
461
​
462
# A POSIX-style path to copy the artifacts to, relative to the project artifacts directory at
463
# `.garden/artifacts`.
464
target: .
465
​
466
# The command/entrypoint used to run the test inside the container.
467
command:
468
​
469
# Key/value map of environment variables. Keys must be valid POSIX environment variable names (must not start with
470
# `GARDEN`) and values must be primitives or references to secrets.
471
env: {}
472
​
473
cpu:
474
# The minimum amount of CPU the test needs to be available for it to be deployed, in millicpus (i.e. 1000 = 1
475
# CPU)
476
min: 10
477
​
478
# The maximum amount of CPU the test can use, in millicpus (i.e. 1000 = 1 CPU)
479
max: 1000
480
​
481
memory:
482
# The minimum amount of RAM the test needs to be available for it to be deployed, in megabytes (i.e. 1024 = 1
483
# GB)
484
min: 90
485
​
486
# The maximum amount of RAM the test can use, in megabytes (i.e. 1024 = 1 GB)
487
max: 90
488
​
489
# List of volumes that should be mounted when deploying the test.
490
#
491
# Note: If neither `hostPath` nor `module` is specified, an empty ephemeral volume is created and mounted when
492
# deploying the container.
493
volumes:
494
- # The name of the allocated volume.
495
name:
496
​
497
# The path where the volume should be mounted in the container.
498
containerPath:
499
​
500
# _NOTE: Usage of hostPath is generally discouraged, since it doesn't work reliably across different platforms
501
# and providers. Some providers may not support it at all._
502
#
503
# A local path or path on the node that's running the container, to mount in the container, relative to the
504
# module source path (or absolute).
505
hostPath:
506
​
507
# The name of a _volume module_ that should be mounted at `containerPath`. The supported module types will
508
# depend on which provider you are using. The `kubernetes` provider supports the [persistentvolumeclaim
509
# module](https://docs.garden.io/reference/module-types/persistentvolumeclaim), for example.
510
#
511
# When a `module` is specified, the referenced module/volume will be automatically configured as a runtime
512
# dependency of this service, as well as a build dependency of this module.
513
#
514
# Note: Make sure to pay attention to the supported `accessModes` of the referenced volume. Unless it supports
515
# the ReadWriteMany access mode, you'll need to make sure it is not configured to be mounted by multiple
516
# services at the same time. Refer to the documentation of the module type in question to learn more.
517
module:
518
​
519
# If true, run the test's main container in privileged mode. Processes in privileged containers are essentially
520
# equivalent to root on the host. Defaults to false.
521
privileged:
522
​
523
# POSIX capabilities to add to the running test's main container.
524
addCapabilities:
525
​
526
# POSIX capabilities to remove from the running test's main container.
527
dropCapabilities:
528
​
529
# A list of tasks that can be run from this container module. These can be used as dependencies for services (executed
530
# before the service is deployed) or for other tasks.
531
tasks:
532
- # The name of the task.
533
name:
534
​
535
# A description of the task.
536
description:
537
​
538
# The names of any tasks that must be executed, and the names of any services that must be running, before this
539
# task is executed.
540
dependencies: []
541
​
542
# Set this to `true` to disable the task. You can use this with conditional template strings to enable/disable
543
# tasks based on, for example, the current environment or other variables (e.g. `enabled: \${environment.name !=
544
# "prod"}`). This can be handy when you only want certain tasks to run in specific environments, e.g. only for
545
# development.
546
#
547
# Disabling a task means that it will not be run, and will also be ignored if it is declared as a runtime
548
# dependency for another service, test or task.
549
#
550
# Note however that template strings referencing the task's outputs (i.e. runtime outputs) will fail to resolve
551
# when the task is disabled, so you need to make sure to provide alternate values for those if you're using them,
552
# using conditional expressions.
553
disabled: false
554
​
555
# Maximum duration (in seconds) of the task's execution.
556
timeout: null
557
​
558
# The arguments used to run the task inside the container.
559
args:
560
​
561
# Specify artifacts to copy out of the container after the run. The artifacts are stored locally under the
562
# `.garden/artifacts` directory.
563
#
564
# Note: Depending on the provider, this may require the container image to include `sh` `tar`, in order to enable
565
# the file transfer.
566
artifacts:
567
- # A POSIX-style path or glob to copy. Must be an absolute path. May contain wildcards.
568
source:
569
​
570
# A POSIX-style path to copy the artifacts to, relative to the project artifacts directory at
571
# `.garden/artifacts`.
572
target: .
573
​
574
# 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
575
# your project (or one or more of the task's dependants) is deployed. Otherwise the task is only re-run when its
576
# version changes (i.e. the module or one of its dependencies is modified), or when you run `garden run task`.
577
cacheResult: true
578
​
579
# The command/entrypoint used to run the task inside the container.
580
command:
581
​
582
# Key/value map of environment variables. Keys must be valid POSIX environment variable names (must not start with
583
# `GARDEN`) and values must be primitives or references to secrets.
584
env: {}
585
​
586
cpu:
587
# The minimum amount of CPU the task needs to be available for it to be deployed, in millicpus (i.e. 1000 = 1
588
# CPU)
589
min: 10
590
​
591
# The maximum amount of CPU the task can use, in millicpus (i.e. 1000 = 1 CPU)
592
max: 1000
593
​
594
memory:
595
# The minimum amount of RAM the task needs to be available for it to be deployed, in megabytes (i.e. 1024 = 1
596
# GB)
597
min: 90
598
​
599
# The maximum amount of RAM the task can use, in megabytes (i.e. 1024 = 1 GB)
600
max: 90
601
​
602
# List of volumes that should be mounted when deploying the task.
603
#
604
# Note: If neither `hostPath` nor `module` is specified, an empty ephemeral volume is created and mounted when
605
# deploying the container.
606
volumes:
607
- # The name of the allocated volume.
608
name:
609
​
610
# The path where the volume should be mounted in the container.
611
containerPath:
612
​
613
# _NOTE: Usage of hostPath is generally discouraged, since it doesn't work reliably across different platforms
614
# and providers. Some providers may not support it at all._
615
#
616
# A local path or path on the node that's running the container, to mount in the container, relative to the
617
# module source path (or absolute).
618
hostPath:
619
​
620
# The name of a _volume module_ that should be mounted at `containerPath`. The supported module types will
621
# depend on which provider you are using. The `kubernetes` provider supports the [persistentvolumeclaim
622
# module](https://docs.garden.io/reference/module-types/persistentvolumeclaim), for example.
623
#
624
# When a `module` is specified, the referenced module/volume will be automatically configured as a runtime
625
# dependency of this service, as well as a build dependency of this module.
626
#
627
# Note: Make sure to pay attention to the supported `accessModes` of the referenced volume. Unless it supports
628
# the ReadWriteMany access mode, you'll need to make sure it is not configured to be mounted by multiple
629
# services at the same time. Refer to the documentation of the module type in question to learn more.
630
module:
631
​
632
# If true, run the task's main container in privileged mode. Processes in privileged containers are essentially
633
# equivalent to root on the host. Defaults to false.
634
privileged:
635
​
636
# POSIX capabilities to add to the running task's main container.
637
addCapabilities:
638
​
639
# POSIX capabilities to remove from the running task's main container.
640
dropCapabilities:
641
​
642
# Set this to override the default OpenJDK container image version. Make sure the image version matches the
643
# configured `jdkVersion`. Ignored if you provide your own Dockerfile.
644
imageVersion:
645
​
646
# POSIX-style path to the packaged JAR artifact, relative to the module directory.
647
jarPath:
648
​
649
# The JDK version to use.
650
jdkVersion: 8
651
​
652
# Options to add to the `mvn package` command when building.
653
mvnOpts: []
654
​
655
# Use the default Dockerfile provided with this module. If set to `false` and no Dockerfile is found, Garden will
656
# fallback to using the `image` field.
657
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
Required
array[string]
No
Example:
1
services:
2
- args:
3
- npm
4
- start
Copied!

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

services[].devMode

​services > devMode
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.
Dev mode is enabled when running the garden dev command, and by setting the --dev flag on the garden deploy command.
See the Code Synchronization guide for more information.
Type
Required
object
No

services[].devMode.args[]

​services > devMode > args
Override the default container arguments when in dev mode.
Type
Required
array[string]
No

services[].devMode.command[]

​services > devMode > command
Override the default container command (i.e. entrypoint) when in dev mode.
Type
Required
array[string]
No

services[].devMode.sync[]

​services > devMode > sync
Specify one or more source files or directories to automatically sync with the running container.
Type
Required
array[object]
No

services[].devMode.sync[].source

​services > devMode > 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
services:
2
- devMode:
3
...
4
sync:
5
- source: "src"
Copied!

services[].devMode.sync[].target

​services > devMode >