helm rollback: Usage, Options & Common CI Errors
Revert a release to a known-good revision.
helm rollback returns a release to an earlier revision, creating a new revision that mirrors the old state. It is the manual recovery path when an upgrade goes wrong and --atomic was not used.
What it does
helm rollback NAME [REVISION] reverts the release to the given revision (or the immediately previous one if omitted), recorded as a new, higher revision number. helm history NAME lists the revisions to choose from. --wait blocks on readiness and --force replaces resources that cannot be updated in place.
Common usage
helm history web
helm rollback web 3
helm rollback web # back to the previous revision
helm rollback web 3 --wait --timeout 5mCommon errors in CI
"Error: release: not found" or "revision N not found" means the target revision was purged - history is finite (default --history-max=10 on upgrade), so very old revisions are gone; helm history shows what remains. If the original failure came from --atomic and the auto-rollback itself failed, you can see "release web failed, and has been rolled back" alongside a rollback error, leaving the release in FAILED state. Inspect with helm status and roll back to a known-good revision explicitly. Rollback re-applies the old manifests, so any immutable-field change between revisions can still fail the rollback.
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