Helm migration hooks under GitOps
Helm hooks plus GitOps tension.
use a pre-upgrade hook Job with weights and delete policy; the challenge is GitOps tools render statically and reconcile, conflicting with Helm's imperative hook lifecycle.
ignoring idempotency.
What's really being asked
Whether you know Helm's hook mechanism and understand that its imperative, lifecycle-driven behavior clashes with declarative continuous reconciliation.
The full answer
In Helm you implement the migration as a Kubernetes Job templated in the chart and annotated with helm.sh/hook: pre-upgrade so it runs before the new application pods roll out during an upgrade. Use helm.sh/hook-weight to order multiple hooks and helm.sh/hook-delete-policy, for example before-hook-creation or hook-succeeded, to control cleanup of the Job between runs. The challenge under GitOps is that tools like Argo CD do not invoke Helm's release lifecycle; they render the chart to plain manifests and reconcile them continuously. Helm hooks are translated to the tool's own model, such as Argo CD sync hooks and PreSync phase via argocd.argoproj.io annotations, and a hook Job re-created on every sync can rerun the migration. Therefore migrations must be idempotent, ordering must be expressed in the tool's phases, and you must avoid drift from Jobs lingering or being pruned. Some teams move migrations out of hooks into an explicit, version-gated Job or a dedicated migration step.
The mistakes people make
Assuming Helm pre-upgrade hooks run transparently under Argo CD, ignoring idempotency so a re-sync corrupts data, or putting the migration in an init container where it runs per-pod rather than once.
What usually comes next
How do Argo CD sync phases map to Helm hooks? How do you guarantee a migration runs once? How do you handle failed migrations and rollback?
A concrete example
You add a Job with helm.sh/hook: pre-upgrade and hook-weight "-5" running the migration binary. Under plain Helm it executes before new pods. Under Argo CD, you instead annotate it as argocd.argoproj.io/hook: PreSync; because every sync may recreate it, the migration tool tracks applied versions in the database and exits early if already applied, keeping the operation idempotent.
Interview question
Why must a Helm pre-upgrade migration hook be idempotent when run under a continuously reconciling GitOps controller?
- a.Idempotency is required only for post-install hooks, not pre-upgrade
- b.A re-sync can recreate and rerun the hook Job, so it may execute more than onceCorrect
- c.GitOps controllers run every hook exactly twice by design
- d.Helm hooks are ignored entirely, so the script never runs
Why? this is the answer
Because the controller reconciles declaratively and may recreate the hook Job on each sync, a non-idempotent migration could run repeatedly and corrupt data. The hook is not ignored; it is translated to the controller's own sync phases.
Just read this? Test yourself on what you have been reading.
Read the original → helm.sh
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles