Bundle Overrides
Bundle overrides provide a mechanism to customize Helm charts inside of Zarf packages.
Quickstart
Consider the following zarf.yaml
and values.yaml
which deploys podinfo
with a couple of custom values:
The bundle overrides feature allows users to override the values specified in Zarf packages. For example:
This bundle will deploy the helm-overrides-package
Zarf package and override the replicaCount
, ui.color
, and podAnnotations
values in the podinfo
chart. The values
can’t be modified after the bundle has been created. However, at deploy time, users can override the UI_COLOR
and other variables
using a environment variable called UDS_UI_COLOR
or by specifying it in a uds-config.yaml
like so:
Overrides
Syntax
Consider the following bundle overrides
:
In this example, the helm-overrides-package
Zarf package has a component called helm-overrides-component
which contains a Helm chart called podinfo
; note how these names are keys in the overrides
block. The podinfo
chart has a replicaCount
value that is overridden to 2
, a podAnnotations
value that is overridden to include customAnnotation: "customValue"
and a variable called UI_COLOR
that is overridden to purple
.
Values Files
The valuesFiles
in an overrides
block are a list of file
’s. It allows users to override multiple values in a Zarf package component’s underlying Helm chart, by providing a file with those values instead of having to include them all individually in the overrides
block.
Values
The values
in an overrides
block are a list of path
and value
pairs. They allow users to override values in a Zarf package component’s underlying Helm chart. Note that values are specified by bundle authors and cannot be modified after the bundle has been created.
Path
The path
uses dot notation to specify the location of a value to override in the underlying Helm chart. For example, the replicaCount
path in the podinfo
chart is located at the top-level of the podinfo values.yaml, so the path is simply replicaCount
, while the ui.color
path is located under the ui
key, so the path is ui.color
.
Value
The value
is the value to set at the path
. Values can be simple values such as numbers and strings, as well as, complex lists and objects, for example:
Bundle Variables as Values
Bundle and Zarf variables can be used to set override values by using the syntax ${...}
. For example:
In the example above ${REPLICA_COUNT}
is set in the uds-config.yaml
file and ${COLOR}
is set as an export from the output-var
package. Note that you could also set these values with the shared
key in a uds-config.yaml
, environment variables prefixed with UDS_
or with the --set
flag during deployment.
Value Precedence
Value precedence is as follows:
- The
values
in anoverrides
block values
set in the lastvaluesFile
(if more than one specified)values
set in the previousvaluesFile
(if more than one specified)
Variables
Variables are similar to values in that they allow users to override values in a Zarf package component’s underlying Helm chart; they also share a similar syntax. However, unlike values
, variables
can be overridden at deploy time. For example, consider the variables
key in the following uds-bundle.yaml
:
There are 3 ways to override the UI_COLOR
variable:
-
UDS config: you can create a
uds-config.yaml
file in the same directory as the bundle and specify the variable to override. For example, to override theUI_COLOR
variable, you can create auds-config.yaml
: -
Environment variables: you can create an environment variable prefixed with
UDS_
and the name of the variable. For example, to override theUI_COLOR
variable, you can create an environment variable calledUDS_UI_COLOR
and set it to the desired value. Note that environment variables take precedence overuds-config.yaml
variables. -
—set Flag: you can also override the variable using the CLI’s
--set
flag. For example, to override theUI_COLOR
variable, you can run one of the following commands::warning: Warning: Because Helm override variables and Zarf variables share the same —set syntax, be careful with variable names to avoid conflicts.
Variable Precedence
Variable precedence is as follows:
- The
--set
flag - Environment variables
uds-config.yaml
variables- Variables
default
in theuds-bundle.yaml
Variable Types
Variables can be of either type raw
or file
. The type will default to raw if not set explicitly.
File Paths
If a file path is not absolute, it will be set as relative to the uds-config.yaml
directory.
e.g. the following uds-config.yaml
is in src/test/bundles/07-helm-overrides/variable-files/
This means when test.cert
is evaluated it will first be appended to the config path like so src/test/bundles/07-helm-overrides/variable-files/test.cert
.
If the file path is already set to the same relative path as the config, then no merging will take place.
Sensitive
Variables can be specified as sensitive, which means their values, regardless of how they’re set, will be masked in output.
Namespace
It’s also possible to specify a namespace for a packaged Helm chart to be installed in. For example, to deploy the a chart in the custom-podinfo
namespace, you can specify the namespace
in the overrides
block:
View All Variables
When working with a local or remote bundle you can view all overrides and zarf variables by running uds inspect --list-variables BUNDLE_TARBALL|OCI_REF]