Helm defines nine helm.sh/hook events — which of them fire during helm upgrade, and which cannot?

### The nine events and their commands Helm's hook events are not free-floating labels; each is owned by exactly one command. | Event | Fires when | |---|---| | `pre-install` | `helm install`, after rendering, before any resource is created | | `post-install` | `helm install`, after all of the release's resources are applied | | `pre-upgrade` | `helm upgrade`, after rendering, before any resource is updated | | `post-upgrade` | `helm upgrade`, after all resources have been updated | | `pre-rollback` | `helm rollback`, after rendering the target revision, before it is applied | | `post-rollback` | `helm rollback`, after the target revision has been applied | | `pre-delete` | `helm uninstall`, before any resource is deleted | | `post-delete` | `helm uninstall`, after all resources are deleted | | `test` | `helm test`, against an already-installed release | So `helm upgrade` fires exactly two of the nine. Everything else is inert for that command — the install hooks are not re-run, the test hook is not applied, and the delete hooks are untouched. ### The upgrade --install trap `helm upgrade --install` is the idiom every pipeline uses, because it is a single command that works whether or not the release exists. That is exactly what makes it a trap: when the release does not exist, Helm performs an **install**, and an install fires install hooks. A chart whose schema-migration Job is annotated only `pre-upgrade` will therefore run that Job on the second deploy and every deploy after it, and never on the first — the one deploy where an empty database most needs it. The symptom is a workload that crash-loops on a fresh namespace and comes up fine everywhere the chart has been deployed before. Annotate `pre-install,pre-upgrade` and the problem disappears. ```yaml metadata: annotations: "helm.sh/hook": pre-install,pre-upgrade ``` A comma-separated list on one annotation is the supported form; you do not need two copies of the manifest. ### Rollback does not replay upgrade hooks `helm rollback` re-applies a previous revision's stored manifest, which means it writes the same kinds of objects an upgrade writes. It nevertheless fires `pre-rollback` and `post-rollback`, never the upgrade events. This matters most for data. If your only migration hook is `pre-upgrade`, a rollback restores the old application image against a database the old code may not understand, and nothing runs to reverse the schema change. Helm does not solve that for you; the chart author has to decide, deliberately, whether a `pre-rollback` hook exists and what it does — and in practice most teams answer it by making migrations backward compatible instead. ### Uninstall and test `pre-delete` and `post-delete` are the only chance a chart gets to do something on the way out — deregister from a discovery service, snapshot state, release a lease. They fire on `helm uninstall`, before and after the release's resources are removed. `test` is different in kind from all the others: a manifest annotated `helm.sh/hook: test` is rendered and stored with every operation but applied by nothing except `helm test`, run by a human or a pipeline against a release that is already installed. ### How Helm gets there At each event Helm applies that event's hooks and blocks until they report ready before continuing — for a Job, until it has completed. A hook that fails stops the operation; the rest of that phase does not proceed. Nothing about this changed between Helm 3 and Helm 4, and the event names have been stable for the life of Helm 3. ### The rule of thumb Write the annotation from the *command*, not from the intent. "Run before the app starts" is not an event; `helm install` and `helm upgrade` are two different commands and you must name both if you mean both. Charts that get this wrong usually work in the environment they were developed in — where the release already exists — and break the first time someone deploys them somewhere new.