argocd app sync: Deploy an Application
argocd app sync applies the desired Git state of an Application to the cluster and waits for the operation to finish.
sync is the deploy verb. In a pipeline you trigger it after pushing manifests and then gate on its exit code, which is non-zero if the sync fails.
What it does
argocd app sync reconciles the live cluster state toward the Application source. By default it blocks until the sync operation completes; --prune deletes resources that no longer exist in Git. The exit code reflects success or failure.
Common usage
argocd app sync guestbook --prune --timeout 300
# sync to a specific revision then wait for health
argocd app sync guestbook --revision "$GIT_SHA"
argocd app wait guestbook --health --timeout 300Options
| Flag | What it does |
|---|---|
| --prune | Delete resources removed from Git |
| --revision <ref> | Sync to a specific Git revision |
| --timeout <sec> | Fail if the sync does not finish in time |
| --async | Return immediately without waiting |
| --force | Use kubectl replace/delete instead of apply |
| --resource <group:kind:name> | Sync only selected resources |
In CI
sync waits for the operation but not necessarily for resources to become Healthy; follow it with argocd app wait --health to gate on rollout. With auto-sync enabled, an explicit sync still helps in CI to make the deploy synchronous and fail the job on errors.
Common errors in CI
"FATA[0000] rpc error: code = FailedPrecondition desc = ... another operation is already in progress" means a sync is already running; wait or pass --retry-limit. "ComparisonError: rpc error ... Manifest generation error" points at bad manifests or a missing Helm/Kustomize binary. "one or more synchronization tasks completed unsuccessfully" with hook failures means a Job or hook resource errored.
Using this in CI
A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods
# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info
# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes