include directive to specify which files belong to each module. You will also have to provide the path to the Dockerfile with the dockerfile directive.include: []..gitignore the .garden dir?image field in container modules? Is it for pulling or publishing images?image field is specified and Garden can't find a Dockerfile for the module, Garden will use that image when deploying the module. If there is a Dockerfile, Garden will build the image from it, regardless of whether or not the image field is specified.image field is specified and the module has a Dockerfile, Garden will build the image from the Dockerfile and publish it to the URL specified in the image field. If there's no Dockerfile, the publish command will fail.include/exclude fields? How are they different from the project-level module.include/module.exclude fields? What about ignore files?kubernetes and helm modules to their own namespaces.build.dependencies[] field for that. See e.g. this example project.garden.yml file so that it is at the same level or parent to all relevant build context and use the include field.v-<something> versions mean, and why are they sometimes different between building and deploying?container module) is generally different from the version of a service defined in the same module. This is because the service version also factors in the runtime configuration for that service, which often differs between environments, but we don't want those changes to require a rebuild of the container image.verbose or higher. For example:garden.yml file for the respective module, or in a child directory.garden.yml file to the same level as the Dockerfile and use the include directive to tell Garden what other files belong to the module. For example, if you have the following directory structure:garden.yml file at the root and define your modules likes so:project.garden.yml, api.garden.yml and frontend.garden.yml.dockerfile field. For example:docker-daemon instances for more build concurrency?garden-system namespace?garden-system namespace directly, because Kubernetes may fail to remove persistent volumes. Instead, use this command:garden deploy or garden dev?cacheResult: false is set on the task definition.<project-name>--metadata namespace. You can delete them manually with this command:garden test and garden run testgarden test command can run all your tests, or a subset of your tests, and has a --watch flag. It won't re-run tests that are cached unless the --force flag is set and it won't print the output unless the test fails. See here for the synopsis and examples.garden run test command runs a single test in interactive mode regardless of whether or not it's cached. Interactive mode means that the output is streamed to the screen immediately and you can interact with it if applicable.--interactive false. See here for the full synopsis.--interactive=false the default with our next major release.kubernetes or helm module types for that. Here's the official Kubernetes guide for mounting secrets as files.buildArgs?environment field of tasks, services and tests. See the secrets section of our docs for more.buildArgs are considered a bad practice and a security risk.persistentvolumeclaim module type to store data and share it across modules. See this section of our docs for more.kubectl and by using the Kubernetes APIs directly and should therefore work with all Kubernetes clusters that implement these. Garden is committed to supporting the latest six stable versions of Kubernetes.container modules (e.g. annotations and labels)?helm module type over container in terms of features?local-kubernetes provider defaults to installing Nginx, but the (remote) kubernetes provider does not install it by default.openfaas provider installs some components necessary for OpenFaas to work.kubernetes/system and openfaas/system.*.local.app.garden domain?*.local.app.garden domain resolves to 127.0.0.1 via our DNS provider for convenience. If you want to use a different hostname for local development, you’ll have to add the corresponding entry to your hosts file.