What would break if a Helm chart's hooks specifically relied on helm rollback semantics, and how would that manifest when deployed via Argo CD instead?

Anything depending on Helm's own release-history concept — a pre-rollback hook (which only fires during an actual helm rollback command, never invoked by Argo CD at all), or template logic checking Release.IsUpgrade/Release.IsInstall (which reflects Helm CLI's own install-vs-upgrade distinction) — either never fires or reflects a value that doesn't necessarily match Argo CD's own sync history, since Argo CD tracks sync operations through its own model, not through the Helm CLI's release-object lifecycle at all.

Argo CD's Helm support renders a chart via templating (equivalent to helm template) and applies the result through its own sync engine — it never actually invokes helm install, helm upgrade, or helm rollback as CLI operations, and it doesn't maintain a Helm-CLI-style release history object at all. Anything in a chart that assumes genuine Helm CLI release-lifecycle semantics is checking for something that structurally doesn't exist in Argo CD's deployment model.

pre-rollback/post-rollback hooks never fire under Argo CD: these hooks are specifically tied to the helm rollback command's lifecycle — since Argo CD never runs that command (a "rollback" in Argo CD's world is just syncing to an earlier Git revision, applying rendered manifests the normal way, not invoking Helm's rollback mechanism), any chart logic relying on these specific hooks firing simply never executes under Argo CD, silently — no error, just a hook that never runs.

Release.IsUpgrade/Release.IsInstall may not reflect what's actually happening: these template values are populated by the Helm CLI/SDK based on whether it detected an existing release object for that name — under Argo CD's own model (no genuine Helm release history object being maintained the way the CLI does), whether these values are populated in a way that matches the semantics a chart author expects depends on the specifics of Argo CD's Helm integration and is not guaranteed to align with "is this actually the first deploy or a subsequent one" as a chart author using the plain CLI would expect.

Practical manifestation: a chart that, say, only seeds initial data via a pre-rollback hook, or branches its template logic significantly based on Release.IsUpgrade to handle first-install differently from subsequent upgrades, can behave unexpectedly under Argo CD — not with an error, but with the expected conditional behavior simply not triggering the way it would under plain Helm CLI usage, which can be a subtle, hard-to-diagnose difference specifically because nothing fails loudly.

The fix: verify a chart's dependence on genuine Helm CLI lifecycle semantics before migrating it to Argo CD — auditing for pre-rollback/post-rollback hooks and any template logic branching on Release.IsUpgrade/Release.IsInstall specifically, and either removing that dependence (restructuring the logic to not need it) or explicitly testing the chart's actual behavior under Argo CD to confirm it does what's expected, rather than assuming CLI-tested behavior carries over unchanged.

• Argo CD never invokes helm install/upgrade/rollback as CLI operations, so any chart logic tied to those specific commands' lifecycle (like pre-rollback hooks) silently never fires.
• Release.IsUpgrade/Release.IsInstall values may not reflect genuine first-install-versus-subsequent-deploy state the way they would under direct CLI usage.
• The failure mode is silent (expected conditional logic simply not triggering), not an error — making it a subtle migration risk worth auditing for explicitly.
• Audit for these specific dependencies before migrating a chart to Argo CD, and test actual behavior under Argo CD rather than assuming CLI-tested behavior carries over.

• Argo CD: Helm
• Helm: Chart Hooks
• Helm: Built-in Objects (Release)