# helm test: Command Reference for CI/CD

> Reference for helm test: run a release embedded test hooks to verify a deploy actually works, fetching logs on failure, and a CI post-deploy smoke-test example.

Source: https://latchkey.dev/learn/command-reference/helm-test-command-cli-reference  
Updated: 2026-06-26

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
```

> Always set `--request-timeout` in CI. Without it an unreachable API server hangs until the job times out, which turns a thirty-second failure into a twenty-minute one.

## FAQ

### helm test: Command Reference for CI/CD?

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.

### 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.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt