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 build arguments to use when building the container image.
118
#
119
# Note: Garden will always set a `GARDEN_MODULE_VERSION` argument with the module version at build time.
120
buildArgs: {}
121
​
122
# Specify extra flags to use when building the container image. Note that arguments may not be portable across
123
# implementations.
124
extraFlags:
125
​
126
# Specify the image name for the container. Should be a valid Docker image identifier. If specified and the module
127
# does not contain a Dockerfile, this image will be used to deploy services for this module. If specified and the
128
# module does contain a Dockerfile, this identifier is used when pushing the built image.
129
image:
130
​
131
# Specifies which files or directories to sync to which paths inside the running containers of hot reload-enabled
132
# services when those files or directories are modified. Applies to this module's services, and to services with this
133
# module as their `sourceModule`.
134
hotReload:
135
# Specify one or more source files or directories to automatically sync into the running container.
136
sync:
137
- # POSIX-style path of the directory to sync to the target, relative to the module's top-level directory. Must be
138
# a relative path. Defaults to the module's top-level directory if no value is provided.
139
source: .
140
​
141
# POSIX-style absolute path to sync the directory to inside the container. The root path (i.e. "/") is not
142
# allowed.
143
target:
144
​
145
# An optional command to run inside the container after syncing.
146
postSyncCommand:
147
​
148
# POSIX-style name of Dockerfile, relative to module root.
149
dockerfile:
150
​
151
# A list of services to deploy from this container module.
152
services:
153
- # Valid RFC1035/RFC1123 (DNS) label (may contain lowercase letters, numbers and dashes, must start with a letter,
154
# and cannot end with a dash), cannot contain consecutive dashes or start with `garden`, or be longer than 63
155
# characters.
156
name:
157
​
158
# The names of any services that this service depends on at runtime, and the names of any tasks that should be
159
# executed before this service is deployed.
160
dependencies: []
161
​
162
# Set this to `true` to disable the service. You can use this with conditional template strings to enable/disable
163
# services based on, for example, the current environment or other variables (e.g. `enabled: \${environment.name
164
# != "prod"}`). This can be handy when you only need certain services for specific environments, e.g. only for
165
# development.
166
#
167
# Disabling a service means that it will not be deployed, and will also be ignored if it is declared as a runtime
168
# dependency for another service, test or task.
169
#
170
# Note however that template strings referencing the service's outputs (i.e. runtime outputs) will fail to resolve
171
# when the service is disabled, so you need to make sure to provide alternate values for those if you're using
172
# them, using conditional expressions.
173
disabled: false
174
​
175
# Annotations to attach to the service _(note: May not be applicable to all providers)_.
176
#
177
# When using the Kubernetes provider, these annotations are applied to both Service and Pod resources. You can
178
# generally specify the annotations intended for both Pods or Services here, and the ones that don't apply on
179
# either side will be ignored (i.e. if you put a Service annotation here, it'll also appear on Pod specs but will
180
# be safely ignored there, and vice versa).
181
annotations: {}
182
​
183
# The command/entrypoint to run the container with when starting the service.
184
command:
185
​
186
# The arguments to run the container with when starting the service.
187
args:
188
​
189
# Whether to run the service as a daemon (to ensure exactly one instance runs per node). May not be supported by
190
# all providers.
191
daemon: false
192
​
193
# Specifies which files or directories to sync to which paths inside the running containers of the service when
194
# it's in dev mode, and overrides for the container command and/or arguments.
195
#
196
# Dev mode is enabled when running the `garden dev` command, and by setting the `--dev` flag on the `garden
197
# deploy` command.
198
#
199
# See the [Code Synchronization guide](https://docs.garden.io/guides/code-synchronization-dev-mode) for more
200
# information.
201
devMode:
202
# Override the default container arguments when in dev mode.
203
args:
204
​
205
# Override the default container command (i.e. entrypoint) when in dev mode.
206
command:
207
​
208
# Specify one or more source files or directories to automatically sync with the running container.
209
sync:
210
- # POSIX-style path of the directory to sync to the target, relative to the module's top-level directory.
211
# Must be a relative path. Defaults to the module's top-level directory if no value is provided.
212
source: .
213
​
214
# POSIX-style absolute path to sync the directory to inside the container. The root path (i.e. "/") is not
215
# allowed.
216
target:
217
​
218
# Specify a list of POSIX-style paths or glob patterns that should be excluded from the sync.
219
#
220
# `.git` directories and `.garden` directories are always ignored.
221
exclude:
222
​
223
# The sync mode to use for the given paths. Allowed options: `one-way`, `one-way-replica`,
224
# `one-way-reverse`, `one-way-replica-reverse` and `two-way`.
225
mode: one-way
226
​
227
# The default permission bits, specified as an octal, to set on files at the sync target. Defaults to 0600
228
# (user read/write). See the [Mutagen
229
# docs](https://mutagen.io/documentation/synchronization/permissions#permissions) for more information.
230
defaultFileMode:
231
​
232
# The default permission bits, specified as an octal, to set on directories at the sync target. Defaults to
233
# 0700 (user read/write). See the [Mutagen
234
# docs](https://mutagen.io/documentation/synchronization/permissions#permissions) for more information.
235
defaultDirectoryMode:
236
​
237
# Set the default owner of files and directories at the target. Specify either an integer ID or a string
238
# name. See the [Mutagen
239
# docs](https://mutagen.io/documentation/synchronization/permissions#owners-and-groups) for more
240
# information.
241
defaultOwner:
242
​
243
# Set the default group on files and directories at the target. Specify either an integer ID or a string
244
# name. See the [Mutagen
245
# docs](https://mutagen.io/documentation/synchronization/permissions#owners-and-groups) for more
246
# information.
247
defaultGroup:
248
​
249
# List of ingress endpoints that the service exposes.
250
ingresses:
251
- # Annotations to attach to the ingress (Note: May not be applicable to all providers)
252
annotations: {}
253
​
254
# The hostname that should route to this service. Defaults to the default hostname configured in the provider
255
# configuration.
256
#
257
# Note that if you're developing locally you may need to add this hostname to your hosts file.
258
hostname:
259
​
260
# The link URL for the ingress to show in the console and on the dashboard. Also used when calling the service
261
# with the `call` command.
262
#
263
# Use this if the actual URL is different from what's specified in the ingress, e.g. because there's a load
264
# balancer in front of the service that rewrites the paths.
265
#
266
# Otherwise Garden will construct the link URL from the ingress spec.
267
linkUrl:
268
​
269
# The path which should be routed to the service.
270
path: /
271
​
272
# The name of the container port where the specified paths should be routed.
273
port:
274
​
275
# Key/value map of environment variables. Keys must be valid POSIX environment variable names (must not start with
276
# `GARDEN`) and values must be primitives or references to secrets.
277
env: {}
278
​
279
# Specify how the service's health should be checked after deploying.
280
healthCheck:
281
# Set this to check the service's health by making an HTTP request.
282
httpGet:
283
# The path of the service's health check endpoint.
284
path:
285
​
286
# The name of the port where the service's health check endpoint should be available.
287
port:
288
​
289
scheme: HTTP
290
​
291
# Set this to check the service's health by running a command in its container.
292
command:
293
​
294
# Set this to check the service's health by checking if this TCP port is accepting connections.
295
tcpPort:
296
​
297
# The maximum number of seconds to wait until the readiness check counts as failed.
298
readinessTimeoutSeconds: 3
299
​
300
# The maximum number of seconds to wait until the liveness check counts as failed.
301
livenessTimeoutSeconds: 3
302
​
303
# If this module uses the `hotReload` field, the container will be run with this command/entrypoint when the
304
# service is deployed with hot reloading enabled.
305
hotReloadCommand:
306
​
307
# If this module uses the `hotReload` field, the container will be run with these arguments when the service is
308
# deployed with hot reloading enabled.
309
hotReloadArgs:
310
​
311
cpu:
312
# The minimum amount of CPU the service needs to be available for it to be deployed, in millicpus (i.e. 1000 = 1
313
# CPU)
314
min: 10
315
​
316
# The maximum amount of CPU the service can use, in millicpus (i.e. 1000 = 1 CPU)
317
max: 1000
318
​
319
memory:
320
# The minimum amount of RAM the service needs to be available for it to be deployed, in megabytes (i.e. 1024 = 1
321
# GB)
322
min: 90
323
​
324
# The maximum amount of RAM the service can use, in megabytes (i.e. 1024 = 1 GB)
325
max: 90
326
​
327
# List of ports that the service container exposes.
328
ports:
329
- # The name of the port (used when referencing the port elsewhere in the service configuration).
330
name:
331
​
332
# The protocol of the port.
333
protocol: TCP
334
​
335
# The port exposed on the container by the running process. This will also be the default value for
336
# `servicePort`.
337
# This is the port you would expose in your Dockerfile and that your process listens on. This is commonly a
338
# non-priviledged port like 8080 for security reasons.
339
# The service port maps to the container port:
340
# `servicePort:80 -> containerPort:8080 -> process:8080`
341
containerPort:
342
​
343
# Specify a preferred local port to attach to when creating a port-forward to the service port. If this port
344
# is
345
# busy, a warning will be shown and an alternative port chosen.
346
localPort:
347
​
348
# The port exposed on the service. Defaults to `containerPort` if not specified.
349
# This is the port you use when calling a service from another service within the cluster. For example, if
350
# your service name is my-service and the service port is 8090, you would call it with:
351
# http://my-service:8090/some-endpoint.
352
# It is common to use port 80, the default port number, so that you can call the service directly with
353
# http://my-service/some-endpoint.
354
# The service port maps to the container port:
355
# `servicePort:80 -> containerPort:8080 -> process:8080`
356
servicePort:
357
​
358
# Set this to expose the service on the specified port on the host node (may not be supported by all
359
# providers). Set to `true` to have the cluster pick a port automatically, which is most often advisable if
360
# the cluster is shared by multiple users.
361
# This allows you to call the service from the outside by the node's IP address and the port number set in
362
# this field.
363
nodePort:
364
​
365
# The number of instances of the service to deploy. Defaults to 3 for environments configured with `production:
366
# true`, otherwise 1.
367
# Note: This setting may be overridden or ignored in some cases. For example, when running with `daemon: true`,
368
# with hot-reloading enabled, or if the provider doesn't support multiple replicas.
369
replicas:
370
​
371
# List of volumes that should be mounted when deploying the service.
372
#
373
# Note: If neither `hostPath` nor `module` is specified, an empty ephemeral volume is created and mounted when
374
# deploying the container.
375
volumes:
376
- # The name of the allocated volume.
377
name:
378
​
379
# The path where the volume should be mounted in the container.
380
containerPath:
381
​
382
# _NOTE: Usage of hostPath is generally discouraged, since it doesn't work reliably across different platforms
383
# and providers. Some providers may not support it at all._
384
#
385
# A local path or path on the node that's running the container, to mount in the container, relative to the
386
# module source path (or absolute).
387
hostPath:
388
​
389
# The name of a _volume module_ that should be mounted at `containerPath`. The supported module types will
390
# depend on which provider you are using. The `kubernetes` provider supports the [persistentvolumeclaim
391
# module](https://docs.garden.io/reference/module-types/persistentvolumeclaim), for example.
392
#
393
# When a `module` is specified, the referenced module/volume will be automatically configured as a runtime
394
# dependency of this service, as well as a build dependency of this module.
395
#
396
# Note: Make sure to pay attention to the supported `accessModes` of the referenced volume. Unless it supports
397
# the ReadWriteMany access mode, you'll need to make sure it is not configured to be mounted by multiple
398
# services at the same time. Refer to the documentation of the module type in question to learn more.
399
module:
400
​
401
# If true, run the service's main container in privileged mode. Processes in privileged containers are essentially
402
# equivalent to root on the host. Defaults to false.
403
privileged:
404
​
405
# POSIX capabilities to add to the running service's main container.
406
addCapabilities:
407
​
408
# POSIX capabilities to remove from the running service's main container.
409
dropCapabilities:
410
​
411
# A list of tests to run in the module.
412
tests:
413
- # The name of the test.
414
name:
415
​
416
# The names of any services that must be running, and the names of any tasks that must be executed, before the
417
# test is run.
418
dependencies: []
419
​
420
# Set this to `true` to disable the test. You can use this with conditional template strings to
421
# enable/disable tests based on, for example, the current environment or other variables (e.g.
422
# `enabled: \${environment.name != "prod"}`). This is handy when you only want certain tests to run in
423
# specific environments, e.g. only during CI.
424
disabled: false
425
​
426
# Maximum duration (in seconds) of the test run.
427
timeout: null
428
​
429
# The arguments used to run the test inside the container.
430
args:
431
​
432
# Specify artifacts to copy out of the container after the run. The artifacts are stored locally under the
433
# `.garden/artifacts` directory.
434
#
435
# Note: Depending on the provider, this may require the container image to include `sh` `tar`, in order to enable
436
# the file transfer.
437
artifacts:
438
- # A POSIX-style path or glob to copy. Must be an absolute path. May contain wildcards.
439
source:
440
​
441
# A POSIX-style path to copy the artifacts to, relative to the project artifacts directory at
442
# `.garden/artifacts`.
443
target: .
444
​
445
# The command/entrypoint used to run the test inside the container.
446
command:
447
​
448
# Key/value map of environment variables. Keys must be valid POSIX environment variable names (must not start with
449
# `GARDEN`) and values must be primitives or references to secrets.
450
env: {}
451
​
452
cpu:
453
# The minimum amount of CPU the test needs to be available for it to be deployed, in millicpus (i.e. 1000 = 1
454
# CPU)
455
min: 10
456
​
457
# The maximum amount of CPU the test can use, in millicpus (i.e. 1000 = 1 CPU)
458
max: 1000
459
​
460
memory:
461
# The minimum amount of RAM the test needs to be available for it to be deployed, in megabytes (i.e. 1024 = 1
462
# GB)
463
min: 90
464
​
465
# The maximum amount of RAM the test can use, in megabytes (i.e. 1024 = 1 GB)
466
max: 90
467
​
468
# List of volumes that should be mounted when deploying the test.
469
#
470
# Note: If neither `hostPath` nor `module` is specified, an empty ephemeral volume is created and mounted when
471
# deploying the container.
472
volumes:
473
- # The name of the allocated volume.
474
name:
475
​
476
# The path where the volume should be mounted in the container.
477
containerPath:
478
​
479
# _NOTE: Usage of hostPath is generally discouraged, since it doesn't work reliably across different platforms
480
# and providers. Some providers may not support it at all._
481
#
482
# A local path or path on the node that's running the container, to mount in the container, relative to the
483
# module source path (or absolute).
484
hostPath:
485
​
486
# The name of a _volume module_ that should be mounted at `containerPath`. The supported module types will
487
# depend on which provider you are using. The `kubernetes` provider supports the [persistentvolumeclaim
488
# module](https://docs.garden.io/reference/module-types/persistentvolumeclaim), for example.
489
#
490
# When a `module` is specified, the referenced module/volume will be automatically configured as a runtime
491
# dependency of this service, as well as a build dependency of this module.
492
#
493
# Note: Make sure to pay attention to the supported `accessModes` of the referenced volume. Unless it supports
494
# the ReadWriteMany access mode, you'll need to make sure it is not configured to be mounted by multiple
495
# services at the same time. Refer to the documentation of the module type in question to learn more.
496
module:
497
​
498
# If true, run the test's main container in privileged mode. Processes in privileged containers are essentially
499
# equivalent to root on the host. Defaults to false.
500
privileged:
501
​
502
# POSIX capabilities to add to the running test's main container.
503
addCapabilities:
504
​
505
# POSIX capabilities to remove from the running test's main container.
506
dropCapabilities:
507
​
508
# A list of tasks that can be run from this container module. These can be used as dependencies for services (executed
509
# before the service is deployed) or for other tasks.
510
tasks:
511
- # The name of the task.
512
name:
513
​
514
# A description of the task.
515
description:
516
​
517
# The names of any tasks that must be executed, and the names of any services that must be running, before this
518
# task is executed.
519
dependencies: []
520
​
521
# Set this to `true` to disable the task. You can use this with conditional template strings to enable/disable
522
# tasks based on, for example, the current environment or other variables (e.g. `enabled: \${environment.name !=
523
# "prod"}`). This can be handy when you only want certain tasks to run in specific environments, e.g. only for
524
# development.
525
#
526
# Disabling a task means that it will not be run, and will also be ignored if it is declared as a runtime
527
# dependency for another service, test or task.
528
#
529
# Note however that template strings referencing the task's outputs (i.e. runtime outputs) will fail to resolve
530
# when the task is disabled, so you need to make sure to provide alternate values for those if you're using them,
531
# using conditional expressions.
532
disabled: false
533
​
534
# Maximum duration (in seconds) of the task's execution.
535
timeout: null
536
​
537
# The arguments used to run the task inside the container.
538
args:
539
​
540
# Specify artifacts to copy out of the container after the run. The artifacts are stored locally under the
541
# `.garden/artifacts` directory.
542
#
543
# Note: Depending on the provider, this may require the container image to include `sh` `tar`, in order to enable
544
# the file transfer.
545
artifacts:
546
- # A POSIX-style path or glob to copy. Must be an absolute path. May contain wildcards.
547
source:
548
​
549
# A POSIX-style path to copy the artifacts to, relative to the project artifacts directory at
550
# `.garden/artifacts`.
551
target: .
552
​
553
# 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
554
# your project (or one or more of the task's dependants) is deployed. Otherwise the task is only re-run when its
555
# version changes (i.e. the module or one of its dependencies is modified), or when you run `garden run task`.
556
cacheResult: true
557
​
558
# The command/entrypoint used to run the task inside the container.
559
command:
560
​
561
# Key/value map of environment variables. Keys must be valid POSIX environment variable names (must not start with
562
# `GARDEN`) and values must be primitives or references to secrets.
563
env: {}
564
​
565
cpu:
566
# The minimum amount of CPU the task needs to be available for it to be deployed, in millicpus (i.e. 1000 = 1
567
# CPU)
568
min: 10
569
​
570
# The maximum amount of CPU the task can use, in millicpus (i.e. 1000 = 1 CPU)
571
max: 1000
572
​
573
memory:
574
# The minimum amount of RAM the task needs to be available for it to be deployed, in megabytes (i.e. 1024 = 1
575
# GB)
576
min: 90
577
​
578
# The maximum amount of RAM the task can use, in megabytes (i.e. 1024 = 1 GB)
579
max: 90
580
​
581
# List of volumes that should be mounted when deploying the task.
582
#
583
# Note: If neither `hostPath` nor `module` is specified, an empty ephemeral volume is created and mounted when
584
# deploying the container.
585
volumes:
586
- # The name of the allocated volume.
587
name:
588
​
589
# The path where the volume should be mounted in the container.
590
containerPath:
591
​
592
# _NOTE: Usage of hostPath is generally discouraged, since it doesn't work reliably across different platforms
593
# and providers. Some providers may not support it at all._
594
#
595
# A local path or path on the node that's running the container, to mount in the container, relative to the
596
# module source path (or absolute).
597
hostPath:
598
​
599
# The name of a _volume module_ that should be mounted at `containerPath`. The supported module types will
600
# depend on which provider you are using. The `kubernetes` provider supports the [persistentvolumeclaim
601
# module](https://docs.garden.io/reference/module-types/persistentvolumeclaim), for example.
602
#
603
# When a `module` is specified, the referenced module/volume will be automatically configured as a runtime
604
# dependency of this service, as well as a build dependency of this module.
605
#
606
# Note: Make sure to pay attention to the supported `accessModes` of the referenced volume. Unless it supports
607
# the ReadWriteMany access mode, you'll need to make sure it is not configured to be mounted by multiple
608
# services at the same time. Refer to the documentation of the module type in question to learn more.
609
module:
610
​
611
# If true, run the task's main container in privileged mode. Processes in privileged containers are essentially
612
# equivalent to root on the host. Defaults to false.
613
privileged:
614
​
615
# POSIX capabilities to add to the running task's main container.
616
addCapabilities:
617
​
618
# POSIX capabilities to remove from the running task's main container.
619
dropCapabilities:
620
​
621
# Set this to override the default OpenJDK container image version. Make sure the image version matches the
622
# configured `jdkVersion`. Ignored if you provide your own Dockerfile.
623
imageVersion:
624
​
625
# POSIX-style path to the packaged JAR artifact, relative to the module directory.
626
jarPath:
627
​
628
# The JDK version to use.
629
jdkVersion: 8
630
​
631
# Options to add to the `mvn package` command when building.
632
mvnOpts: []
633
​
634
# Use the default Dockerfile provided with this module. If set to `false` and no Dockerfile is found, Garden will
635
# fallback to using the `image` field.
636
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: #
Garden will import the repository source code into this module, but read the module's config from the local garden.yml file.
Type