Skip to main content
Planned. This page describes designed behaviour that is not built yet. Details may change before it ships.
Ported from Garden’s documentation: garden-for/kubernetes/install-helm-chart.md, gliss-cli at 3bc62a036 (Garden 0.14). Gliss runs Garden under the hood; the notes on this page say where Gliss differs.
In Gliss, helm Deploy actions are available at level 2 only. Your IT team enables level 2 per project, and every release is checked against IT’s policy instead of the catalog. The project still uses the gliss provider: the deploy becomes a signed release request, and the cluster agent applies it. You don’t configure Garden’s kubernetes provider or a kubeconfig.
Helm is one of the most common tools for managing Kubernetes manifests. This page shows how to use third-party charts and your own charts in a Garden project, and how to pass them images you build. If you only need to deploy some manifests and don’t need Helm’s features, use the simpler kubernetes Deploy action instead. The full field list is in Garden’s helm Deploy reference.

​
Reference external charts

To use a chart whose sources aren’t in your project, point to the chart and provide values as inputs. Charts can come from Helm chart repositories (over https) or from OCI-based registries. Your IT team’s policy may restrict which sources you can use.

​
Example: Redis from an OCI registry

​
Example: Redis from a Helm repository

Reference a chart repository with the repo field, for example your organization’s own repository:

​
Local charts

Often you’ll keep the chart sources in your project. Add a garden.yml in the chart directory, next to Chart.yaml, and give the action a name:
You can also reference chart sources in another repository:

​
Provide values to the chart

The simplest way to pass parameters to the chart is the spec.values field:
Garden writes the values to a YAML file and passes it to Helm when it renders the chart. This is handy when you want to template the values (see the next section). You can also list your own value files, with paths relative to the directory that contains the garden.yml:
In this example, some.key is "prod-value" in the prod environment, and other.key keeps the default from values.default.yaml. Values in the values field take precedence over both value files.
In Gliss, don’t put secret values in values or value files. Secret values are set through Gliss secret requests, and your configuration refers to secrets by name only.
When a container Build produces an image that a helm Deploy uses, make the Build a dependency, so the image is built first, and pass its name and version to the chart:
The shape of the chart’s values.yaml decides how you pass the image (this example follows the default template from helm create). If the chart uses several images, add each Build as a dependency and reference it under values. For a complete example, see Garden’s vote-helm project.

​
Tests and runs

To run tests against a chart, see Tests and runs.
In Gliss, Garden’s sync mode and spec.sync don’t apply. Live code changes are Git-backed and work in Preview only, through gliss dev.