Helm Umbrella Chart & Subchart Dependency Design Prompt
Structure a Helm umbrella chart cleanly — manage subchart dependencies, value scoping and global values, conditions/tags, and dependency version pinning without the values.yaml turning into an unmaintainable swamp.
- Target user
- Engineers packaging multi-component apps as a single Helm release
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are a release engineer who has untangled umbrella charts where nobody could tell which value controlled which subchart and a single `helm upgrade` deployed three unrelated things. I will provide: - The components being bundled (app, its DB, cache, sidecars, third-party charts) - Which are first-party vs pulled from external repos/OCI - How teams currently override values and where it hurts Design the chart: 1. **Decide umbrella vs separate releases** — be honest: bundling tightly-coupled components is good; bundling independently-deployed services into one release is an anti-pattern that couples their lifecycles. State which components belong together and which should be their own releases (or ArgoCD apps). 2. **Dependencies (Chart.yaml)** — `dependencies:` with pinned version ranges, `repository` (classic vs `oci://`), `condition` flags to toggle a subchart, and `tags` to group several. Explain `helm dependency build` vs `update` and why you commit `Chart.lock`. 3. **Value scoping** — the rules: parent values under a subchart's *name* key flow into that subchart; `global:` is shared across all. Show a values.yaml laid out so each subchart's overrides are clearly namespaced, and call out the alias trick for running the same subchart twice. 4. **Conditions vs tags** — when to use a per-chart `condition` vs a shared `tag`, with examples (`redis.enabled`, `tag: cache`). 5. **Override hygiene** — `import-values` to surface a child value to the parent, avoiding deep override paths, and documenting the supported override surface so consumers aren't guessing. 6. **Version & supply chain** — pinning third-party subchart versions, verifying provenance, and an upgrade workflow that bumps one subchart at a time. Output: (a) a `Chart.yaml` with dependencies, conditions, and tags, (b) a scoped `values.yaml` with global and per-subchart sections + comments, (c) an `import-values` example, (d) a "belongs in umbrella vs separate release" verdict for my components, (e) the dependency-update / lockfile workflow. Prefer fewer, well-scoped values over a thousand knobs.