Release Announcement: Garden 0.12.33

Garden 0.12.33 is out! :tada:

This release introduces module varfiles, which add even more flexibility to module-specific variables. This is especially useful for larger projects, and when using module templates.

In addition, this release includes a few bug fixes and improvements.

See the changelog in the release notes for a full list of changes.

Many thanks to @janario for his contribution to this release!

Module varfiles

To use a module-level varfile, simply configure the module.varfile field to be the relative path (from module root) to the varfile you want to use for that module. For example:

# my-service/garden.yml
kind: Module
name: my-service
# Here, we use per-environment module varfiles as an optional override for variables (these have a higher precedence
# than those in the `variables` field below).
#
# If no varfile exists, no error is thrown (we simply don't override any variables).
varfile: my-service.${environment.name}.yaml
variables:
  # This overrides the project-level hostname variable
  hostname: my-service.${var.hostname}
  # You can specify maps or lists as variables
  envVars:
    LOG_LEVEL: debug
    DATABASE_PASSWORD: ${var.database-password}
services:
  - name: my-service
    ...
    ingresses:
      - path: /
        port: http
        # This resolves to the hostname variable set above, not the project-level hostname variable
        hostname: ${var.hostname}
    # Referencing the above envVar module variable
    env: ${var.envVars}
tests:
  - name: my-test
    ...
    # Re-using the envVar module variable
    env: ${var.envVars}

Module varfiles must be located inside the module root directory. That is, they must be in the same directory as the module configuration, or in a subdirectory of that directory.

Note that variables defined in module varfiles override variables defined in project-level variables and varfiles

Happy hacking!