How does Helm resolve a chart dependency's tags list, and what wins when condition and tags disagree?

### The two switches Helm gives a chart author two ways to make a dependency optional, both declared on the entry in `Chart.yaml`: ```yaml dependencies: - name: postgresql version: 15.3.2 repository: https://charts.example.internal condition: postgresql.enabled tags: - bundled-datastores - name: valkey version: 3.1.4 repository: https://charts.example.internal tags: - bundled-datastores - cache ``` `condition` points at one values path and governs exactly one dependency. `tags` is a list of labels; several dependencies can share a label, so one value flips them together. ### Where the tags map lives Tags are matched against a `tags:` map at the **top level** of the values the release is rendered with - not under the subchart's key, and not inside the subchart's own `values.yaml`: ```yaml tags: bundled-datastores: false cache: true ``` That single map is shared by the whole chart tree, which is the point: it is a set of cross-cutting feature switches rather than per-chart configuration. It also means tag names are effectively a global namespace, so an umbrella chart that pulls in third-party subcharts can find two unrelated charts responding to the same tag name. ### The resolution rule For each dependency, Helm looks at the tags it lists and checks which of them appear in the tags map: - if **any** listed tag is present and true, the dependency is enabled; - if the listed tags that are present are **all** false, the dependency is disabled; - if **none** of its tags appears in the map, the dependency keeps its default state, which is enabled. So tags are OR-ed, and truth wins over falsehood. In the example above, `valkey` lists `bundled-datastores` (false) and `cache` (true): because one of them is true, it is enabled. A candidate who assumes any false tag vetoes the chart gets this backwards, and it is the single most common misunderstanding of the feature. ### Precedence When a dependency has both, and its condition path resolves to a boolean, **the condition wins** - the tag outcome is overwritten. `postgresql` above lists a tag that is false, but if the values also set `postgresql.enabled: true`, the subchart renders. The precedence is one-directional and unconditional in that sense; the only way tags decide a dependency that also has a condition is for the condition to resolve to nothing at all, which happens when the path is absent or holds a non-boolean. That ordering is what makes the pair usable: the tag is the coarse default for a family of components, and the condition is the escape hatch for the one component someone needs to differ. A platform team can ship `tags.bundled-datastores: false` in the production values file and still let one service keep its bundled cache by setting that chart's own condition key. ### When to reach for tags Honestly, rarely. Most real charts use conditions only, because a condition key sits in the same values namespace as the rest of that subchart's configuration, reads naturally in a diff (`postgresql.enabled: false` next to `postgresql.host`), and cannot be flipped by accident from an unrelated part of the values tree. Tags earn their place when one umbrella chart carries a set of components that genuinely move together - a whole in-cluster dependency stack that exists for local development and is switched off everywhere else - and you want one line in the production values file rather than six. The cost is discoverability. A reader of `values.yaml` sees `tags: {bundled-datastores: false}` and cannot tell from that file which dependencies it governs; they have to read `Chart.yaml`, and for a nested tree, several of them. Document the tag names in the chart's README if you use them, and prefer conditions when the switch belongs to exactly one component.