jib-container

Description

Extends the container module type to build the image with Jib. Use this to efficiently build container images for Java services. Check out the jib example to see it in action.
The image is always built locally, directly from the module source directory (see the note on that below), before shipping the container image to the right place. You can set build.tarOnly: true to only build the image as a tarball.
By default (and when not using remote building), the image is pushed to the local Docker daemon, to match the behavior of and stay compatible with normal container modules.
When using remote building with the kubernetes provider, the image is synced to the cluster (where individual layers are cached) and then pushed to the deployment registry from there. This is to make sure any registry auth works seamlessly and exactly like for normal Docker image builds.
Please consult the Jib documentation for how to configure Jib in your Gradle or Maven project.
To provide additional arguments to Gradle/Maven when building, you can set the extraFlags field.
Important note: Unlike many other module types, jib modules are built from the module source directory instead of the build staging directory, because of how Java projects are often laid out across a repository. This means build.dependencies[].copy directives are effectively ignored, and any include/exclude statements and .gardenignore files will not impact the build result. Note that you should still configure includes, excludes and/or a .gardenignore to tell Garden which files to consider as part of the module version hash, to correctly detect whether a new build is required.
Below is the full schema reference. For an introduction to configuring Garden modules, please look at our Configuration guide.
The first section contains the complete YAML schema, and the second section describes each schema key.
jib-container modules also export values that are available in template strings. See the Outputs section below for details.

Complete YAML Schema

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

build > projectType
The type of project to build. Defaults to auto-detect between gradle and maven (based on which files/directories are found in the module root), but in some cases you may need to specify it.
Type
Default
Required
string
"auto"
No

build.jdkVersion

build > jdkVersion
The JDK version to use.
Type
Default
Required
number
11
No

build.tarOnly

build > tarOnly
Don't load or push the resulting image to a Docker daemon or registry, only build it as a tar file.
Type
Default
Required
boolean
false
No

build.tarFormat

build > tarFormat
Specify the image format in the resulting tar file. Only used if tarOnly: true.
Type
Default
Required
string
"docker"
No

build.extraFlags[]

build > extraFlags
Specify extra flags to pass to maven/gradle when building the container image.
Type
Required
array[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