What "Hook Support" Means Here

A repository document, rendered for the site. View source markdown.

Generated at: 2026-07-30T12:38:02.000Z UTC · source: committed helm-expt evidence for this rendered repository document.

UNOFFICIAL/EXPERIMENTAL

Helm hooks are phaseful actions, not objects. Render parity proves an object set; it proves nothing about whether a pre-upgrade migration ran before the workload updated. So this repo never says a chart's hooks "work." It gives every hook-bearing top-100 chart exactly one disposition, in data/hook-disposition/, enforced by a verifier that fails when a hook-bearing chart has none.

The Dispositions

DispositionWhat it claimsWhat it does not claim
observedA maintained lifecycle receipt exists from a live run: the hook's resources were inventoried, a route was selected, and the runtime outcome was observed, with a freshness timestamp.That the hook works on other bases, values profiles, chart versions, or cluster classes. Receipts age; the next action is always keep-fresh.
routedA route is selected in the lifecycle vocabulary (preflight, Argo/Flux lifecycle hook, explicit managed action, upgrade action, delete cleanup) and worked evidence exists: rendered hook resources extracted from the pinned chart, plus a live rehearsal that ran or a blocker receipt with the exact failing command output.Any live behavior. A route is a classification with evidence, not an execution proof.
per-targetThe honest route differs by target cluster class (for example, GKE Autopilot preflight synchronizers vs an ordinary migration Job).That any single route claim covers all targets.
refusedThe hook behavior is explicitly out of support, with a refusal receipt naming why.Nothing - that is the point. A refusal is a published claim boundary.
recipe-neededA route plan exists, but the chart has no maintained recipe, so no lifecycle work can attach to a base yet.That the chart or its hooks are deficient. The gap is catalog work, not chart quality.

Three Rules That Keep This Honest

  1. Dependency-provided hooks count. The disposition table's dependency_source column names the vendored subchart that ships a hook (kong inside kubernetes-dashboard, minio inside thanos, traefik inside gitlab). Chart-level review that skips the dependency closure undercounts.
  2. Values-conditional hooks are proven by rendering both paths. The worked evidence under data/hook-disposition/evidence/ renders the default and the hook-enabled profile and records both digests. A source scan count is neither an undercount alarm nor a support claim until the render shows when the hooks actually materialize - kubernetes-dashboard's hooks do not render at all under default values, and airflow's migrations default to a plain Deployment.
  3. A blocked rehearsal is evidence, not failure. The kafka and minio rehearsals reached real target preconditions and blocked because pinned upstream image tags no longer resolved. Those receipts - with the exact pull errors or preconditions - are stronger trust artifacts than untested green rows, and they route the real precondition (an image-override, digest-pinned base, or newer chart version) into the next action.

Where The Evidence Lives