helm test: Command Reference for CI/CD

By Kaveh Alemi·Latchkey

Run a release embedded tests to verify the deploy works.

helm test runs the test hooks a chart ships (pods annotated helm.sh/hook: test) against an installed release, turning "it deployed" into "it works". This reference covers the flags and a post-deploy CI smoke-test pattern.

Common flags and usage

test <release>: run the chart test hooks against the release
--logs: stream the test pod logs (always use in CI)
--timeout 5m: bound how long tests may run
--filter name=<test>: run a specific test
Exits non-zero if any test pod fails

Example

shell

helm upgrade --install web ./charts/web \
  --set image.tag=${IMAGE_TAG} --wait --atomic --timeout 5m
helm test web --logs --timeout 5m

In CI

Run helm test right after a successful upgrade --install as a smoke test against the live release. Always pass --logs so a failing test prints why in the job output instead of just exiting non-zero. A non-zero exit fails the pipeline, which is what you want.

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.

Terminal

# 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

Key takeaways

helm test verifies the deploy works, not just that it applied.
Always pass --logs so failures are diagnosable in CI output.
Run it after upgrade --install --wait as a post-deploy smoke test.

Frequently asked questions

helm test: Command Reference for CI/CD?

In CI?