tpl: Rendering Strings from Values

The second argument to tpl is the scope used during rendering. Passing the root dot lets the string reach Values and Release.

Now a user can store a dynamic string in values, like a hostname built from the release name, and have it expand at render time.

In your template, pass that field through tpl with the root context to turn the stored placeholder into a real value.

A direct reference prints the raw braces as text. Only tpl actually evaluates the embedded directives inside the stored string.

You can also feed file contents to tpl, letting a bundled config file include release-specific placeholders.

The context need not be the root. Pass any dict so the rendered string sees exactly the variables you choose.

Charts often let users template ingress hosts or annotations this way, keeping flexible config in values rather than templates.

If the stored string has a typo, tpl fails at render time, so test with helm template after adding templated values.

Since a templated host can contain dots or colons, pipe the tpl result through quote so the final YAML value stays a safe string.

You learned that tpl evaluates template strings stored in values or files, using a context you supply such as the root dot. 🎉