helm lint: Usage, Options & Common CI Errors
Catch chart problems before they reach a cluster.
helm lint examines a chart for issues - malformed Chart.yaml, template errors, and best-practice violations - and is a fast first gate in any chart CI pipeline.
What it does
helm lint CHART validates the chart's structure and metadata and attempts to render its templates, reporting INFO, WARNING, and ERROR findings. --strict promotes warnings to failures (the right setting for CI), and --values lets you lint against the same values you will deploy, catching value-dependent template bugs.
Common usage
helm lint ./charts/web
helm lint ./charts/web --strict
helm lint ./charts/web -f values.prod.yaml
helm lint ./charts/* # lint every chartCommon errors in CI
lint returns non-zero on ERROR findings, which is what fails the CI job - common ones are "chart metadata is missing these dependencies" (run helm dependency update), "icon is recommended" (a WARNING that --strict turns into a failure), and template render errors when a required value is absent. Lint without --values uses defaults, so a chart that only breaks with production values passes locally; always lint with -f the real values file in CI. lint is not a substitute for helm template. It does not validate the rendered YAML against the cluster schema, only that templates render.
Using this in CI
A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods
# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info
# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes