helm get: Usage, Options & Common CI Errors
Pull back exactly what a live release was deployed with.
helm get reads information about an installed release from the cluster: the values it was rendered with, the manifests it applied, its hooks, or its notes. It is how you recover the truth of what is actually running.
What it does
helm get values NAME prints the user-supplied values for the release (add -a/--all for the full computed values including chart defaults); get manifest prints the rendered Kubernetes objects; get hooks and get notes print those; get all combines everything. --revision inspects a past revision rather than the current one.
Common usage
helm get values web -n prod
helm get values web -a # full merged values
helm get manifest web | kubectl diff -f -
helm get values web --revision 4Common errors in CI
The key gotcha: plain helm get values returns only the overrides you passed, not the chart defaults - so it looks empty for a release installed with no --set. Use -a/--all to get the effective values, which is what you want when reproducing a release or migrating it. "Error: release: not found" means wrong name/namespace/revision. helm get values -a is invaluable in CI for capturing a release's real configuration before an upgrade, so you can diff and roll forward deliberately.
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