How would you verify a Helm chart's hooks behave correctly under Argo CD before migrating a production chart from helm install to GitOps?

Deploy the chart via Argo CD to a non-production environment first, and directly observe each hook actually firing at the expected point in the sync lifecycle (via Argo CD's own sync operation logs/events, not assuming it worked because no error appeared), specifically checking for any hook tied to Helm CLI-specific lifecycle events (pre-rollback, Release.IsUpgrade branching) that might not translate — combined with a deliberate test of the exact scenarios the hooks are meant to handle (a fresh install, an upgrade, and if relevant, a rollback-equivalent) rather than just a single happy-path deploy.

Deploy to a non-production Argo CD-managed environment first: the direct way to verify hook behavior is observing it actually happen — deploying the chart via Argo CD (not just reading the chart's hook annotations and reasoning about them abstractly) to a staging or test environment lets you directly confirm each hook fires, in what order, and produces the expected effect.

Check Argo CD's own sync operation details, not just "did the sync succeed": Argo CD's UI/CLI shows the sync operation's phases and which resources were applied as hooks at each phase (PreSync/Sync/PostSync) — reviewing this directly confirms which hooks actually ran as part of the sync, rather than assuming a successful overall sync means every hook fired as intended.

Specifically test each lifecycle scenario the hooks are meant to handle: a chart's hooks might behave differently (or not fire at all) depending on whether it's a fresh install versus a subsequent upgrade — testing only one scenario (say, just the initial install) risks missing a problem that only manifests on upgrade (or vice versa). If the chart has any rollback-related hook logic, specifically test Argo CD's equivalent of a "rollback" (syncing back to a prior Git revision) to confirm the chart behaves as expected in that case too, given the earlier point that Helm's own pre-rollback hooks won't fire under Argo CD at all.

Audit the chart's hook annotations and template logic explicitly, in parallel with dynamic testing: cross-referencing the chart's actual helm.sh/hook annotations and any Release.IsUpgrade/Release.IsInstall template branches against what was dynamically observed confirms the static analysis and the observed runtime behavior agree — catching a case where something looked like it should work based on the chart's structure but didn't actually manifest correctly when tested.

Compare against the chart's behavior under plain Helm CLI as a baseline: running the same chart via plain helm install/upgrade in a separate test, and comparing its hook behavior against the Argo CD-deployed version, directly surfaces any discrepancy between the two execution models for this specific chart — the most concrete possible verification that migrating this particular chart won't silently change its behavior.

• Deploy the chart via Argo CD to a non-production environment and directly observe hook execution through Argo CD's own sync operation details, not just an overall success/failure status.
• Test each relevant lifecycle scenario (fresh install, upgrade, rollback-equivalent) separately, since hook behavior can differ between them.
• Cross-reference static analysis (the chart's hook annotations and template logic) against dynamically observed behavior to confirm they agree.
• Comparing behavior directly against a plain helm install/upgrade baseline for the same chart gives the most concrete verification of any discrepancy the migration would introduce.

• Argo CD: Helm
• Argo CD: Resource hooks
• Helm: Chart Hooks