Found while auditing PR #16. Pre-existing on master.
Problem
values.yaml:
# -- Render Job hook annotations (set false for ArgoCD / Flux)
useHelmHooks: true
With useHelmHooks: false the migration Job renders as an ordinary release resource carrying only argocd.argoproj.io/hook: PreSync and BeforeHookCreation. ArgoCD honours those and deletes the Job before re-creating it, so ArgoCD is fine.
Flux's helm-controller is different: it executes a real helm upgrade and supports helm hooks natively. The ArgoCD annotations mean nothing to it, so the Job is applied as a normal resource. spec.template on a Job is immutable, and any release that changes the pod template (new env, a new mount, an appVersion bump changing the image tag or the app.kubernetes.io/version label) makes the API server reject the patch:
Job.batch "<release>-authup-server-migration" is invalid: spec.template: Invalid value: ...: field is immutable
So the advice is not just unhelpful for Flux, it turns a working upgrade into a failing one.
Suggested fix
Either narrow the doc comment to ArgoCD only (set false for ArgoCD), or make the non-hook path safe under real helm by giving the Job a content-derived name suffix so each release creates a new Job rather than patching the old one. The comment change is the smaller of the two and is correct today; the rename is the one that makes the value actually usable under Flux.
Found while auditing PR #16. Pre-existing on master.
Problem
values.yaml:With
useHelmHooks: falsethe migration Job renders as an ordinary release resource carrying onlyargocd.argoproj.io/hook: PreSyncandBeforeHookCreation. ArgoCD honours those and deletes the Job before re-creating it, so ArgoCD is fine.Flux's helm-controller is different: it executes a real
helm upgradeand supports helm hooks natively. The ArgoCD annotations mean nothing to it, so the Job is applied as a normal resource.spec.templateon a Job is immutable, and any release that changes the pod template (new env, a new mount, anappVersionbump changing the image tag or theapp.kubernetes.io/versionlabel) makes the API server reject the patch:So the advice is not just unhelpful for Flux, it turns a working upgrade into a failing one.
Suggested fix
Either narrow the doc comment to ArgoCD only (
set false for ArgoCD), or make the non-hook path safe under real helm by giving the Job a content-derived name suffix so each release creates a new Job rather than patching the old one. The comment change is the smaller of the two and is correct today; the rename is the one that makes the value actually usable under Flux.