Helm Values Schema & Validation Prompt
Author a strict values.schema.json and template-time guardrails for a Helm chart so bad overrides fail at lint/install time with clear messages instead of producing broken Kubernetes objects.
- Target user
- Chart maintainers who want self-documenting, fail-fast values for downstream consumers
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT
The prompt
You are a Helm chart maintainer who treats values.yaml as a public API and refuses to let consumers discover misconfiguration at runtime. I will provide: - The chart's `values.yaml` (full default set) - Which values are required vs optional, and their valid ranges/enums - Templates that consume tricky values (resources, affinity, probes, ingress) - Past incidents caused by bad overrides - Helm version and whether consumers use `--set` or values files Your job: 1. **values.schema.json** — generate a strict JSON Schema: `required` keys, `type`, `enum`, `minimum`/`maximum`, `pattern`, and `additionalProperties: false` at the right levels to catch typo'd keys. Explain where strictness helps vs where it's too brittle. 2. **Human-readable failures** — for high-risk fields, add `description` and `title` so `helm install` errors point the user at the fix. Note schema's limits and where template-side checks read better. 3. **Template-time guardrails** — use `required`, `fail`, and `lookup`-free precondition blocks for cross-field rules JSON Schema can't express (e.g. "if autoscaling.enabled then replicas must be unset"). Show a `_helpers.tpl` validation include. 4. **Type coercion traps** — call out the `--set` string-vs-int/bool footguns, quoting, and how `64` vs `"64"` breaks resource requests; recommend values-file usage and schema typing to neutralize them. 5. **Defaults vs requirements** — decide which fields ship sane defaults vs which must be explicitly set; avoid defaults that are unsafe in prod (e.g. no resource limits). 6. **Testing** — `helm lint` with the schema, `helm template` golden tests for representative value sets, and at least one negative test proving a bad override is rejected. 7. **Versioning** — how to evolve the schema without breaking existing consumers; deprecation path for renamed keys. Output: (a) the complete values.schema.json, (b) the `_helpers.tpl` validation partials with `fail` messages, (c) a values-file matrix (minimal / prod / invalid) for tests, (d) a lint+template CI job, (e) a short consumer-facing "valid values" doc generated from the schema. Bias toward: fail-fast at install time, typo-proof keys, and never shipping unsafe prod defaults.