Overriding Library Defaults Locally

A good library sets sensible defaults yet lets each consumer adjust them. The main lever is the values the partial reads at render time.

Because partials read .Values, your chart customizes shared output simply by setting those keys in its own values.yaml.

Well-written partials wrap reads in the default function, so an unset value falls back gracefully instead of rendering empty.

To change one default, set only that key in your values. The library keeps every other fallback, so you override the minimum needed.

Need bigger changes? Redefine the named template in your own chart. The last define for a name wins, so your version replaces the library's.

When two charts define the same template name, Helm uses the one loaded last. Your application chart can deliberately shadow a library partial.

Often cleaner: define a new partial that includes the library one, then appends your extra fields. You extend without losing upstream logic.

Instead of the root dot, hand a partial a narrowed context so it reads from a subtree of your values, reshaping its output per call.

For finer control, construct a dict mixing the root and overrides, then pass it in. The partial sees exactly the values you assembled.

Always run helm template after overriding to verify your values or redefined partial produced the manifest you intended.

Lean on values first and redefine partials only when necessary. Small, local overrides keep your chart aligned with library upgrades.

Your chart and its library both define common.labels. Which definition does Helm actually use?

Customize a library through values first, redefine or wrap partials when needed, pass custom scope, then verify with helm template. ✅