Garden 0.12.24 is out! 🎉

This release includes several bugfixes and improvements to performance and stability.

It also introduces module-level variables, which are great for reducing clutter in the project configuration of large projects. More on those below!

Many thanks to @toqueteos for his contribution to this release, and to everyone who's been providing feedback and suggestions—happy hacking!

Module-level variables

Each Garden module can now specify its own set of variables, that can be re-used within the module, as well as referenced by other dependant modules.

If your project variable list is becoming cluttered with variables that are only used by a single module (or a subset of them), then these module-level variables can help keep things tidy.

Simply specify the variables field on the module, same as in the project configuration. For example:

kind: Module
name: my-service
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 resolved to the hostname variable set above,
        # not the project-level one
        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}

Notice that you can override variables defined at the project-level, and even reference project-scoped variables when defining the module variables.

Also notice the generally handy use-case of re-using a common value (in this case a map of environment variables) in multiple spots in the module configuration.

Referencing module variables

On top of that, you can reference the resolved module variables in other modules. With the above example, another module might for example reference ${modules.my-service.var.hostname}. For larger projects this can be much cleaner than, say, hoisting a lot of variables up to the project level.

Template strings in remote source configs

Template strings in remote sources now have access to the var key, among many others.

This adds a lot of flexibility when using remote sources in conjunction with automation (e.g. when using dynamic Git branches / tags for remote sources, depending on project- and environment-level variables).

See the template variable reference for remote sources for a full list of variables available in remote source configs.

Changelog

Features

config: add support for module-level variables (0828c5e1)
core: allow variables in remote sources (4d65cb2d)
template: add yamlEncode and yamlDecode template helpers (dbaf972f)

Improvements

core: add get tests command (d610afdd)

Bug Fixes

helm manifest (2ad5e33d)
core: inconsistency in include/exclude handling for submodules (9162b5f5)
core: don't apply dev mode to PVC modules (a8c70e86)
core: log outputs from exec service deploy at verbose level (113f2881)
k8s: ingressClass wasn't respected in cert-manager integration (17e183ab)
k8s: logs command wouldn't get logs from all pods (a6d22fd5)
k8s: error copying artifacts with new version of tar in image (e0debafd)
k8s: missing stderr in verbose buildkit+kaniko build logs (2746fcfb)
k8s: apply toleration to kaniko build pods (f8e19868)
k8s: omit probes in runner pod spec (7826be72)

garden-io/garden 0.12.24 on GitHub