29 questions foundConfigure the Job's own backoffLimit and restartPolicy for pod-level retries, and ArgoCD's sync retry (syncPolicy.retry) to re-run the operation. Combine with BeforeHookCreation so each retry starts a fresh Job rather than colliding with the failed one.
spec: # Job spec
backoffLimit: 3
template:
spec:
restartPolicy: OnFailure
Real-world example A flaky migration hook retries three times at the pod level before the sync is considered failed.
Common follow-ups: What controls Job-level retries? | How does BeforeHookCreation help retries?
Applications Sync & Health Sync Waves & Hooks
Yes—hooks honor the sync-wave annotation within their phase, so multiple PreSync hooks can be ordered (e.g., provision in wave -2, migrate in wave -1). This gives fine control over multi-step preparation or teardown sequences inside a single sync.
metadata:
annotations:
argocd.argoproj.io/hook: PreSync
argocd.argoproj.io/sync-wave: "-1"
Real-world example Provisioning runs in an earlier PreSync wave than the migration that depends on it.
Common follow-ups: Do hooks respect waves? | How do you order two PreSync hooks?
Applications Sync & Health Sync Waves & Hooks
When pruning, ArgoCD reverses wave order—higher waves are deleted before lower ones—so dependents are removed before their dependencies (mirroring creation order). This prevents deleting a prerequisite while something still depends on it.
Real-world example On teardown, the frontend (wave 2) is pruned before the database (wave 1), the reverse of deployment order.
Common follow-ups: Why reverse order for deletion? | How does this protect dependencies?
Applications Sync & Health Sync Waves & Hooks
Run-to-completion resources like Jobs are ideal because ArgoCD tracks their success/failure to gate the sync. Pods can work for simple tasks, but Jobs give retries, completions, and clean semantics for migrations, tests, and one-off tasks.
Real-world example Migrations and smoke tests are Jobs so ArgoCD can wait for completion and detect failure.
Common follow-ups: Why not use a Deployment as a hook? | What do Jobs provide over bare Pods?
Applications Sync & Health Sync Waves & Hooks
Hooks run each time a sync applies them. To force a hook (like tests) to run every sync even without changes, ensure the resource differs (e.g., generateName or a changing annotation) or trigger a sync explicitly. For run-once semantics, use appropriate delete policies and stable naming.
metadata:
generateName: smoke-test-
Real-world example Using generateName makes a fresh smoke-test Job on every sync rather than skipping an unchanged one.
Common follow-ups: How do you force a hook to rerun? | What gives run-once behavior?
Applications Sync & Health Sync Waves & Hooks
Add a PostSync hook Job that calls the external system (webhook, deployment tracker, ChatOps). Because it runs only after resources are Healthy, it reliably signals a completed deployment. Alternatively, use the Notifications controller for event-driven alerts without a hook.
metadata:
annotations:
argocd.argoproj.io/hook: PostSync
Real-world example A PostSync hook posts a 'deployed' event to the release dashboard once the app is healthy.
Common follow-ups: Hook vs Notifications controller for alerts? | Why PostSync for deployment notifications?
Sync & Health Applications Sync Waves & Hooks
Too many waves/hooks slow syncs (each wave waits for health), complicate debugging, and can hide ordering assumptions. Long-running or flaky hooks stall deployments. Keep ordering minimal, make hooks fast and idempotent, and prefer proper readiness/health over artificial waits.
Real-world example A team collapses excessive waves after syncs became slow, keeping only the essential CRD-before-workload ordering.
Common follow-ups: Why can many waves slow syncs? | How do you keep hooks reliable?
Applications Sync & Health Sync Waves & Hooks
The Sync phase is the main phase where the application's regular resources are applied. Sync-phase hooks run alongside these resources. PreSync runs before this phase and PostSync after it completes and is Healthy.
Real-world example The Deployment and Service apply during the Sync phase, between the PreSync migration and PostSync tests.
Common follow-ups: What runs in the Sync phase? | How does it relate to Pre/PostSync?
Applications Sync & Health Sync Waves & Hooks
Use a PreSync or Sync hook Job with BeforeHookCreation deletion and idempotent seeding logic, or gate it so re-runs are no-ops. Because hooks run each sync, the seed script itself should detect existing data and skip, giving effectively run-once behavior safely.
metadata:
annotations:
argocd.argoproj.io/hook: PostSync
argocd.argoproj.io/hook-delete-policy: HookSucceeded
Real-world example A seed Job checks whether the table is populated and exits early on subsequent syncs.
Common follow-ups: How do you make seeding idempotent? | Why can't you assume run-once?
Applications Sync & Health Sync Waves & Hooks