helm list: Usage, Options & Common CI Errors
See every release, its revision, and its status.
helm list (alias ls) enumerates releases with their namespace, revision, status, and chart version. It is the first command to run when you are not sure what is deployed where.
What it does
helm list shows deployed releases in the current namespace; -A spans all namespaces. By default it hides failed/uninstalled releases - --all (-a) includes them, and --failed / --pending / --uninstalling filter by status. -o json or -o yaml gives machine-readable output for CI scripts.
Common usage
helm list -A
helm list -n prod
helm list --all # include failed/pending/uninstalled
helm list -o json | jq '.[].name'
helm list --pendingCommon errors in CI
The usual confusion is a release that "is not there": by default helm list hides releases that are not in deployed status, so a failed install or a pending-upgrade release is invisible until you add --all. A script that checks helm list for a name to decide install-vs-upgrade can therefore make the wrong call. Prefer helm status NAME (which errors clearly if absent) or just always use upgrade --install. Remember releases are namespaced; without -A or the right -n you simply will not see releases in other namespaces.
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