Why does `helm get manifest` omit a release's hook resources, and which command shows them?

### The render is partitioned before anything is applied Rendering a chart produces a stream of YAML documents. Before Helm applies any of it, it sorts the documents into two piles by looking for one annotation: - a document carrying `helm.sh/hook` is a **hook**. Helm records it along with the events it is attached to, its `helm.sh/hook-weight` ordering and its `helm.sh/hook-delete-policy`, and runs it at the appropriate point in the operation. - everything else is part of the release's **manifest**: the set of objects Helm applies and then stores as the definition of that revision. `helm get manifest <release>` prints the second pile only. That is not an omission bug; it reflects how Helm models the two kinds of object. The manifest is the desired state Helm owns and reconciles across upgrades. Hooks are one-shot work attached to an event, and Helm does not track them as part of the release's resource set. ### The practical consequence Someone inspecting the release `tileserv` in namespace `geo` - a geospatial tile server installed from an 18-chart umbrella called `tile-platform` - goes looking for the schema-migration Job the team swears runs before every upgrade: ``` $ helm get manifest tileserv -n geo | grep -c 'kind: Job' 0 ``` Nothing. The natural conclusion, that the chart never rendered it, is wrong: ``` $ helm get hooks tileserv -n geo | grep -A2 'helm.sh/hook:' helm.sh/hook: pre-upgrade helm.sh/hook-weight: "-5" helm.sh/hook-delete-policy: before-hook-creation,hook-succeeded ``` The Job is there, it is a `pre-upgrade` hook, and its delete policy explains a second puzzle: `kubectl get jobs -n geo` may show nothing either, because the object was deleted once it succeeded. The manifest Helm stores and the objects currently alive in the namespace are two different questions, and hooks are the place where they diverge most sharply. ### The rest of the `get` family `helm get` has one subcommand per stored artefact of a release: - `helm get manifest` - the applied, non-hook YAML for a revision. - `helm get hooks` - the hook manifests, annotations intact. - `helm get values` - the configuration, user-supplied or (with `--all`) computed. - `helm get notes` - the rendered `NOTES.txt`, which is otherwise only seen once, in the output of the install that produced it. - `helm get metadata` - a compact, machine-readable summary of the release: its name, namespace, revision, chart name and version, appVersion, status and deployment time. It is the one to reach for from a script, because it is structured by design rather than being human output you have to parse. - `helm get all` - every one of the above in a single stream, which is what you want when you are about to open a ticket or hand the state to a colleague. `--revision N` works across the family, so you can pull the manifest and hooks of an older revision as easily as the current one. ### Reading `helm get manifest` correctly Two further points regularly separate a confident answer from a shaky one. First, this output is what Helm **stored**, not a fresh render. It reflects the chart version and the values that were in effect when that revision was created. If the chart has moved on in your repository, the stored manifest will not match a render of the working copy, and that difference is meaningful information rather than an error. Second, it is a statement about what Helm applied, not about what is running now. Confirming that the live objects still match what the manifest says is a separate step with separate tools. ### Why Helm splits them at all The two piles have different lifecycles, which is the real reason for the partition. The release manifest is desired state that Helm owns: on the next upgrade Helm compares the new manifest against the stored one, and a resource that has disappeared from the chart is deleted from the cluster because Helm knows it used to be part of the set. Hooks are not in that set. They are one-shot work bound to an event, so Helm never reconciles them across revisions and never deletes a hook object because the chart stopped rendering it - the only thing that removes a hook object is its own delete policy, or a person. Keeping the two piles separate in the stored record is what makes that difference expressible at all, and it is why the inspection commands are separate too. ### Why this is a differentiator rather than a screening question Nobody is rejected for not knowing that hooks live outside the manifest. But an engineer who has spent twenty minutes grepping `helm get manifest` for a Job that was always a hook remembers the split permanently, and the answer shows that a candidate has actually inspected releases rather than only installing them.