What does helm lint check in a chart, and what does it not catch?

## What lint is, and what it is not `helm lint` is a static check over chart *source*. You point it at a chart directory or a packaged `.tgz` (`helm lint ./charts/fanout-operator`) and it applies a fixed set of rules, printing findings at three severities and a one-line summary of how many charts were linted and how many failed. It is the cheapest gate a pull request can run: no cluster, no credentials, no container, milliseconds. It is emphatically not `helm test`. That command installs nothing and asserts nothing on its own; it runs test-annotated Pods against a release that is already installed in a cluster. Lint is the opposite end of the pipeline — it runs before anything exists. ## The rules it applies Roughly two families. **Chart-shaped rules.** `Chart.yaml` must exist and parse; `apiVersion` and `name` must be present; the directory the chart lives in must have the same name as the `name` field; `version` must be valid SemVer; `values.yaml`, if present, must parse as YAML; a missing `templates/` directory is reported; a missing `icon` is an informational nudge, not a failure. **Render rules.** Lint actually renders the chart. Every file under `templates/` is executed as a Go template against the coalesced values, and the output is parsed as YAML. A missing function, a bad pipeline, an `index` into a nil value, a `required` helper that fires, unbalanced indentation that produces unparseable YAML — all of these surface here as errors, and they are the findings lint is genuinely good at. Lint also compares the `apiVersion`/`kind` pairs in the rendered output against a list of Kubernetes API versions it knows to have been removed, so a chart still emitting a long-dead API version gets flagged. **Values-schema rules.** If the chart ships a `values.schema.json`, lint validates the coalesced values against it before rendering, so a wrong type or a missing required key fails at lint time rather than at install time. ## Severities and exit codes Findings print as `[INFO]`, `[WARNING]` or `[ERROR]`. By default the command exits non-zero only when at least one ERROR was reported — warnings are advisory. `--strict` promotes warnings so that they fail the run too, which is what you normally want in CI once a chart is clean. `--quiet` suppresses the informational chatter and prints only warnings and errors. ## The values you pass are the coverage you get This is the part candidates miss. Lint renders with the values it has: the chart's own `values.yaml` plus anything you supply with `-f`, `--set`, `--set-string` or `--set-file`. A template body wrapped in `{{- if .Values.metrics.enabled }}` where the default is `false` is never executed, so a syntax error inside it is invisible to a default lint run and ships to whoever turns the flag on. The practical consequence is that lint is run once per supported values combination, not once per chart. Similarly, `--with-subcharts` is needed for the metadata rules to be applied to each dependency under `charts/` as its own chart. Files under `crds/` are never templated at all, so nothing in your values changes them and nothing lint does exercises them. ## What it cannot catch Everything downstream of *is this valid YAML*. Lint has no Kubernetes object schema, so `replicas: three` in a Deployment, a misspelled `contaienrs` key, a Service `targetPort` that no container exposes, a name longer than the 63 characters Kubernetes allows for a Service, a selector that matches nothing — none of them are lint findings. It cannot see the cluster's real Kubernetes version or its installed CRDs, cannot know whether an image tag exists, and has no opinion about whether the resulting workload would ever become ready. That gap defines the rest of a chart's pre-merge suite: lint proves the chart renders, a values schema proves the inputs are shaped correctly, assertions over `helm template` output prove the rendered objects say what you meant, and only a server-side dry run or a real install proves the API server will accept them. ## Using it in CI Run it per values file, with `--strict`, as the first step — it is fast and its failures are unambiguous. Treat a clean lint as a statement about syntax and metadata, never as a statement about correctness.