> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/continuous-delivery/use-gitops/application/sync-gitops-applications.md). # Sync GitOps applications Sync GitOps applications from the Applications page or a GitOps Sync pipeline step, including optional resource-type filters Sync is a process that ensures that the live state of a system matches its desired state by applying a declarative description. This process synchronizes the desired Git state with the live cluster state. *** ## What you will learn from this topic * How to [sync a single-source application](#sync-a-single-source-application) from the Applications page or a GitOps Sync pipeline step * How to set [success criteria](#success-criteria) for the GitOps Sync step * How to [sync specific resource types](#sync-specific-resource-types-in-the-gitops-sync-step) in the GitOps Sync step * How to [confirm resource pruning](#confirm-resource-pruning) when a sync waits for approval before it prunes resources * How to use the [GitOps Sync step parameter reference](#gitops-sync-step-parameter-reference) * How to [sync a multiple-sources application](#sync-a-multiple-sources-application), [terminate sync](#terminate-sync), and [bulk sync or refresh](#bulk-sync-and-refresh) * How to configure [sync notifications](#sync-notifications) *** ## Before you begin Confirm the following before you sync applications: * **GitOps application**: Create a GitOps application that targets the service, environment, and cluster you intend to sync. Go to [Harness GitOps quickstart](/continuous-delivery/use-gitops/get-started/harness-cd-git-ops-quickstart.md) to create an application. * **Pipeline alignment (GitOps Sync step)**: When you use the GitOps Sync pipeline step, the service, environment, and cluster selected in the pipeline must match the service, environment, and cluster in the application. * **Permissions**: Bulk Sync requires the `gitops app sync` permission. Bulk Refresh requires the `gitops app view` permission. * **Agent version (bulk operations)**: Bulk Sync and Refresh require GitOps agent version 0.93 or higher. An incorrect agent version can cause bulk syncs to time out after three minutes. *** ## Sync a single-source application You can sync from the **Applications** page or from a pipeline **GitOpsSync** step. ### Sync from the Applications page Perform the following steps to sync applications from the **Applications** page: 1. In your GitOps project, go to **Deployments** -> **GitOps** -> **Applications**, then select your application. ![GitOps Applications list](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-fc65c24f8bbeab3a8dda0858ade504a008667161%2Fsync-applications-3.png?alt=media) 2. Sync the selected application using one of the following paths: * Select the more options icon, then select **Sync**. ![Sync from the more options menu](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-5911bdb8f4173b31d724aadbfa54702695f6f215%2Fsync-applications-1.png?alt=media) * Select the application, then select **SYNC**. ![SYNC button on the application](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-d10bf7d19dc958d9720dc9e3703e84cb3a8aa10c%2Fsync-applications-2.png?alt=media) 3. Configure the sync options, then select **Synchronize**. When you synchronize the application, you can apply a specific revision. By default, Harness selects the target revision of the application. The **Branch** and **Tag** options display a list of available branches and tags. The **Ref** option lets you synchronize branches, tags, and commit hashes. ### Sync with the GitOps Sync step Perform the following steps to sync applications using the **GitOpsSync** step: 1. Select a pipeline and go to the **Execution** tab of a Deploy stage.

Match service, environment, and cluster

Make sure that the service, environment, and cluster selected in the pipeline match the service, environment, and cluster in the application.

2. Select **Add Step**, then select the **GitOpsSync** step. 3. Select the GitOpsSync step to configure step parameters. 4. In **Success Criteria**, select when you want the step to succeed. Go to [Success criteria](#success-criteria) for the available options and how each one affects the rest of the step. 5. Optionally, select **Wait until healthy** if you want the step to run until the application reaches its **Healthy** state. This option applies only when **Success Criteria** is **Sync Succeeded**. 6. Optionally, if you enabled **Wait until healthy**, you can enable **Fail If Step Times Out**. This causes the step to fail if it times out while waiting for the health check to pass.

Fail If Step Times Out behavior

If this option is enabled, the step can sync successfully but still fail if a healthy state is not achieved before the timeout period expires. If this option is disabled, the step is marked successful when the sync succeeds, regardless of the healthy state.

7. In **Advanced Configuration**, select the application you want to sync and configure the sync options. You can choose an application or applications manually, or you can match up to 1000 applications using a regex filter. The regex field uses **Go (Golang) regex syntax**, not JEXL. You can test your patterns at [regex101](https://regex101.com/) with the **Golang** flavor selected. ![GitOps Sync step regex filter](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-5902a3abf633e7d970a8deab9574e513211a166b%2Fgitopssync-step-regex.png?alt=media) To sync only specific resource types instead of the entire application, select **Application Name**, then go to [Sync specific resource types in the GitOps Sync step](#sync-specific-resource-types-in-the-gitops-sync-step). 8. Select **Apply Changes**. The following image shows how resources look in Harness after the sync process completes. ![Resources after a successful GitOps sync](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-05827c0f486d4e9a4ac3c456ae6681f9cc1e3030%2Fharness-git-ops-application-set-tutorial-40.png?alt=media) *** ## Success criteria The **Success Criteria** field controls when the GitOps Sync step succeeds. * **Sync Succeeded** (`syncSucceeded`, default): The step succeeds only after Argo CD reports the sync operation as complete, and, if **Wait until healthy** is enabled, after the application also reaches **Healthy**. This is unchanged from existing behavior, so pipelines that do not set **Success Criteria** are not affected. * **Sync Initiated** (`syncInitiated`): The step succeeds as soon as Argo CD accepts the sync request. Harness does not poll for the sync operation's outcome or the application's health. ![GitOpsSync step Success Criteria dropdown, showing Sync Succeeded and Sync Initiated options](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-939718dc660a75dbe66f5f62b42a309498ab5f65%2Fgitops-sync-successcriteria.png?alt=media) Select **Sync Initiated** when a resource in the application's sync wave, such as an Argo Rollout, waits on a manual promotion or an external process that would otherwise keep the sync from ever completing. For example, an application that combines an Argo Rollout with **Prune resources at last** (`pruneResourcesAtLast`) creates an implicit sync wave: pruning cannot run until the rollout finishes, but the rollout is paused waiting on a manual promotion, so the sync never completes and the step times out. **Sync Initiated** is also useful when you validate the sync with your own scripts instead of relying on Harness to poll for health. With **Sync Initiated**, the step succeeds as soon as Argo CD accepts the sync request, and fails only if the application fails before the request is sent or Argo CD rejects the request. {% hint style="warning" %} **Success Criteria has incompatible settings** **Wait until healthy**, **Show Resource Progress**, and **Select Promote Option for Rollouts** all depend on polling the sync operation after it starts, so none of them work with **Sync Initiated**. Harness disables and resets these fields in the UI when you select **Sync Initiated**, and rejects the combination at save time and at runtime, including when **Success Criteria** or **Wait until healthy** is a runtime input or an expression that resolves to an incompatible combination. {% endhint %} Because Harness does not track the outcome of the sync operation when **Success Criteria** is **Sync Initiated**, note the following: * **No verification of sync completion or health.** A successful step means Argo CD accepted the sync request, nothing more. * **The application output fields are empty.** `syncStatus` and `syncedRevision` on the step's output applications are `null`, because Harness never observes a post-sync state. An expression that reads either field evaluates to `null`. * **An in-flight sync is not adopted, but the step still succeeds.** If a sync was already running when the step ran, for example because auto-sync is enabled on the application, the step's own sync request, including its sync options and target revision, was never sent. Harness logs a warning and marks the step successful. * **Discovered rollouts can be incomplete.** The step still populates `discoveredRollouts` so that a GitOps Rollout step can act on its output, but discovery reads the application's resource tree as of the pre-sync refresh, with no further wait. A commit that lands in the short window between that refresh and the sync request may not be reflected, so `discoveredRollouts` can be partial or empty. A discovery failure logs a warning and does not fail the step. **Success Criteria** is also available on the [GitOps Rollback step](/continuous-delivery/use-gitops/application/rollback-gitops-applications.md#step-parameter-reference), with the same two values, the same default, and the same restriction against combining **Sync Initiated** with **Wait until healthy**. **Success criteria examples** An existing pipeline that does not set **Success Criteria** keeps its current behavior: ```yaml - step: type: GitOpsSync spec: waitTillHealthy: true failOnTimeout: true ``` To trigger a sync without waiting for it to complete: ```yaml - step: type: GitOpsSync timeout: 10m spec: successCriteria: syncInitiated waitTillHealthy: false ``` The step succeeds within seconds of Argo CD accepting the sync request, with no completion or health check. You can set **Success Criteria** and **Wait until healthy** as runtime inputs and resolve them differently per environment, for example `syncInitiated` in a lower environment and `syncSucceeded` in production. Harness allows this at save time, because the incompatible combination is not yet known, and checks it again once the inputs resolve at runtime: ```yaml - step: type: GitOpsSync spec: successCriteria: <+input> waitTillHealthy: <+input> ``` *** ## Sync specific resource types in the GitOps Sync step By default, the GitOps Sync step synchronizes every resource in a GitOps application. Use the **Configure Resources** filter to limit sync to specific Kubernetes resource types, such as `ConfigMap`, `Deployment`, or `ReplicaSet`. This does not let you cherry-pick individual resources from a list. You select resource types in **Kind**, and optionally narrow the sync with **Group**, **Name**, and **Namespace** patterns. Harness synchronizes all resources in the application that match your filters. {% hint style="info" %} **Minimum versions** This feature requires ng-manager v1.154.0 and next-gen-ui v1.141.0. {% endhint %} ### Resource filter prerequisites Confirm the following before you configure resource filters: * **Manual application selection**: Select **Application Name** in the GitOps Sync step. Resource filters are not available when you target applications with **Application Regex**, **Application Labels**, or **Fetch Linked Apps**. * **Argo CD behavior**: Resource filtering uses the same capabilities Argo CD provides for selective sync. Any limitation in Argo CD also applies in Harness. ### Configure resource filters Perform the following steps to configure resource filters: 1. In your pipeline, open the GitOps Sync step. 2. In **Advanced Configuration**, under **Application Selection**, select **Application Name**. 3. Select the GitOps application you want to sync. 4. Select **Configure Resources**. 5. In the **Resource Selection** dialog, set filters for each application row: * **Group**: Filter by API group. For example, `apps` or `.*` to match all groups. * **Kind**: Select one or more Kubernetes resource types to sync, such as `Deployment`, `ConfigMap`, or `ReplicaSet`. All resources of the selected kinds in the application are synchronized. * **Name**: Filter by resource name pattern. For example, `my-app` or `.*`. * **Namespace**: Filter by namespace pattern. For example, `default` or `.*`. 6. Select **Save**, then select **Apply Changes** on the step. ![Configure Resources filter in the GitOps Sync step](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-40b43e3f1cf2be693ea2e17e9e7bbcf2d39142b5%2Fgitopssync-configure-resources.png?alt=media) After the pipeline runs, only resources that match your filters are synchronized. Resources outside the selected kinds or filter patterns remain unchanged by this sync step. {% hint style="info" %} **Supported application selection modes** Resource filters are available only when you select applications by name. They do not work with **Application Regex**, **Application Labels**, or **Fetch Linked Apps**. {% endhint %} *** ## Confirm resource pruning Pruning deletes cluster resources that are no longer in Git. For critical resources, such as namespaces, you can require an approval before the sync prunes them. This is the Argo CD `Prune=confirm` sync option, and Harness GitOps lets you review and approve the prune from the Harness application or from a pipeline, without cluster access or the Argo CD CLI. ### Prune confirmation behavior A sync waits for approval when a resource has the `argocd.argoproj.io/sync-options: Prune=confirm` annotation, or when the application has `Prune=confirm` in its sync options. While the sync waits, it stays in the **Running** state and does not end until someone approves the prune or you terminate the sync. The gate has the following behavior: * **All or nothing**: One approval covers all resources the sync is about to prune. You cannot approve some resources and not others. * **No deny option**: You can approve the prune or leave it waiting. To stop the prune, terminate the sync. Go to [Terminate sync](#terminate-sync) for details. * **One sync only**: An approval applies to the running sync. The next sync that needs to prune waits for its own approval. * **Prune must be enabled**: The gate only asks for approval. If the sync does not have **Prune** selected, the resources are not deleted after you approve. Select **Prune**, then confirm to delete the resources. You can set the gate in three places. An annotation on a resource, or the application sync option, applies every time the application syncs. The sync option on a GitOps Sync step applies only to that step.
Resource annotation example ```yaml apiVersion: v1 kind: ConfigMap metadata: name: demo-config-map namespace: annotations: argocd.argoproj.io/sync-options: Prune=confirm data: key: value1 ``` When `demo-config-map` is removed from Git, the sync waits in the **Running** state until you confirm the prune.
Application-level sync option example ```yaml spec: syncPolicy: syncOptions: - Prune=confirm ``` Every prunable resource in the application requires confirmation.
For the Argo CD behavior, go to [Resource pruning with confirmation](https://argo-cd.readthedocs.io/en/latest/user-guide/sync-options/#resource-pruning-with-confirmation) in the Argo CD documentation. ### Require confirmation when you sync an application Perform the following steps to require confirmation for a single sync: 1. Go to your GitOps application and select **Sync**. 2. In **Sync Options & Policy**, select **Confirm Before Pruning**. 3. Select **Prune** if you want the resources to be deleted after you approve. 4. Select **Synchronize**. ![Confirm Before Pruning option in the Sync panel](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-5a85c01640d9e64830f6e1bd2b1c505a4a69db2b%2Fgitops-sync-confirm-before-pruning-option.png?alt=media) If a resource has the `Prune=confirm` annotation, the sync waits for approval even when you do not select **Confirm Before Pruning**. ### Confirm a prune from the application When a sync is waiting for prune confirmation, the application details page shows a **Sync waiting for prune confirmation** message, and the resource tree highlights the resources that are waiting. Perform the following steps to approve the prune: 1. In your GitOps project, go to **Deployments** -> **GitOps** -> **Applications**, then select your application. 2. In the **Sync waiting for prune confirmation** message, select **Review and Confirm**. 3. In the **Confirm Pruning** dialog, review the resources that the sync will prune. 4. Select **Confirm**. ![Confirm Pruning dialog on the application](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-15395d0ced7ba3898d9eacd1fa515b59d4274f23%2Fgitops-application-confirm-pruning-dialog.png?alt=media) The sync resumes and prunes resources if **Prune** is enabled. If no sync is running, or no resource is waiting for confirmation, Harness rejects the request with an error. Harness records an audit entry that identifies the user who confirmed the prune. ### Confirm a prune in a GitOps Sync step The GitOps Sync step has two options for prune confirmation. Both options are in the step's **Advanced Configuration**. The GitOps Rollback step offers only the second option. Go to [Confirm a prune in the GitOps Rollback step](/continuous-delivery/use-gitops/application/rollback-gitops-applications.md#confirm-a-prune-in-the-gitops-rollback-step) for details. * **Confirm before pruning**: This step requires confirmation before pruning, the same as the application sync option. This option is available only in the GitOps Sync step. * **Auto-confirm prune** (`autoConfirmPrune`): The step approves the prune itself, so nothing waits for a person. This option is available in the GitOps Sync and GitOps Rollback steps. {% hint style="warning" %} **Avoid turning on both options** The two options work together, because **Auto-confirm prune** approves the wait that **Confirm before pruning** creates. Turning on both at the same time is discouraged, because the step then requires confirmation and approves it immediately. Use **Auto-confirm prune** mainly when your resources carry the `Prune=confirm` annotation, so the step approves those gates while manual syncs of the application still wait for a person. {% endhint %} ![Confirm before pruning and Auto-confirm prune options in the GitOps Sync step](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-349c24428eb7fa2f7ad1b8e57f025f769097cc5a%2Fgitops-sync-step-prune-confirmation-options.png?alt=media) If you do not select **Auto-confirm prune**, the step stays in the **Running** state while a sync waits for approval. Perform the following steps to approve the prune from the pipeline execution. The GitOps Rollback step shows the same review and confirm view. 1. Open the pipeline execution and select the GitOps Sync step. On the **Details** tab, the step shows **Action Required** and lists each waiting application, along with its agent and the number of resources to prune. 2. Select **Review**. 3. In the **Confirm Pruning** dialog, select an application to review the resources that it will prune. 4. Select **Confirm for** the application, or select **Confirm All** to approve every application. ![GitOps Sync step waiting for prune confirmation](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-148208a7448491709c72b315f5066cf6657cb5e2%2Fgitops-sync-step-waiting-prune-confirmation.png?alt=media) ![Confirm Pruning dialog in the pipeline execution](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-51271751e640c6765924cbace093f9accbcaca2a%2Fgitops-sync-step-confirm-pruning-dialog.png?alt=media) The step continues after you confirm. You can approve from the pipeline execution or from the application, and both approve the same sync. For example, you can start the sync from a pipeline and approve it from the application. {% hint style="warning" %} **Step timeout** The step keeps its timeout while it waits. If no one approves the prune before the step timeout (10 minutes by default), the step times out. {% endhint %} With **Auto-confirm prune** selected, the step approves the prune the first time it detects that the sync is waiting, on the next status poll, and the **Review** option does not appear.
GitOps Sync step with autoConfirmPrune example ```yaml - step: type: GitOpsSync name: Sync identifier: Sync spec: applicationsList: - agentId: applicationName: prune: true autoConfirmPrune: true timeout: 10m ```
The same `autoConfirmPrune` field is available on the [GitOps Rollback step](/continuous-delivery/use-gitops/application/rollback-gitops-applications.md#step-parameter-reference). {% hint style="warning" %} **Success Criteria and automatic approval** Automatic approval needs at least one status poll to detect that the sync is waiting. When **Success Criteria** is **Sync Initiated**, the step does not poll the sync operation, so `autoConfirmPrune` has no effect. {% endhint %} ### Agent version support Confirming a prune requires a GitOps Agent version that supports the feature. When you confirm a prune against an older agent, the request fails with a message prompting an upgrade. For a customer-managed Argo CD version that does not support `Prune=confirm`, the annotation is ignored, and the resource is pruned immediately. In that case, no confirmation prompt appears, and a step with `autoConfirmPrune: true` completes as usual. *** ## GitOps Sync step parameter reference The following YAML example shows GitOps Sync step parameters and common UI field mappings.
GitOps Sync step YAML example ```yaml - step: type: GitOpsSync name: GitOps Sync identifier: GitOpsSync spec: applicationsList: # UI: "Application Name" - auto-populated by Fetch Linked Apps - agentId: my-agent applicationName: my-app # applicationRegex: "^payments-.*" # UI: "Application Regex" - Go regex, max 1000; not JEXL # applicationLabels: # UI: "Application Labels" - Key:Value label selectors # - "env:production" prune: false # UI: "Prune" - delete cluster resources absent from Git dryRun: false # UI: "Dry Run" - preview without applying to cluster applyOnly: false # UI: "Apply Only" - skip pre/post-sync hooks and sync waves forceApply: false # UI: "Force Apply" - delete and recreate instead of patch showResourceProgress: true # UI: "Show Resource Progress" - stream per-resource status to logs autoConfirmPrune: false # approve Prune=confirm gates automatically; default false successCriteria: syncSucceeded # UI: "Success Criteria" - syncSucceeded | syncInitiated # syncInitiated is incompatible with waitTillHealthy: true, # showResourceProgress: true, and autoPromoteRolloutBehavior waitTillHealthy: true # UI: "Wait until healthy" - must be false when successCriteria: syncInitiated failOnTimeout: false # UI: "Fail If Step Times Out" - only meaningful when waitTillHealthy: true degradedStateTimeout: "0" # UI: "Degraded State Timeout" - duration string (e.g. "30s", "5m") # max time app may stay Degraded before step fails; "0" = disabled # transient degraded states (for example, rolling updates) can trigger this early autoPromoteRolloutBehavior: null # promote-full | resume | retry | abort | restart # omit if not using Argo Rollouts resourcesFilter: # scope sync to specific resource types (applicationsList only) group: apps kind: Deployment name: ".*" namespace: default label: "app=my-app" syncOptions: skipSchemaValidation: false autoCreateNamespace: false pruneResourcesAtLast: false applyOutOfSyncOnly: false replaceResources: false serverSideApply: false respectIgnoreDifferences: false prunePropagationPolicy: foreground # foreground | background | orphan retryStrategy: limit: 3 baseBackoffDuration: "5s" increaseBackoffByFactor: 2 maxBackoffDuration: "3m" timeout: 10m ```
**Application selection (use one):** | Parameter | Type | Required | Description | | -------------------------------------------- | ------------------- | -------- | ------------------------------------------------------------------------------------------------------------ | | **Application Name** (`applicationsList`) | `list` | No | Explicit `{agentId, applicationName}` pairs. Auto-populated when Fetch Linked Apps ran earlier in the stage. | | **Application Regex** (`applicationRegex`) | `string` (Go regex) | No | Matches up to 1000 app names. Not JEXL. | | **Application Labels** (`applicationLabels`) | `list` | No | `Key:Value` label selectors. Partial matches also consider service and environment names. | **Sync behaviour:** | Parameter | Type | Required | Description | | --------------------------------------------------- | --------- | ------------ | ---------------------------------------------------------------------------------------------------------------------------- | | **Prune** (`prune`) | `boolean` | No (`false`) | Delete cluster resources absent from Git. | | **Dry Run** (`dryRun`) | `boolean` | No (`false`) | Preview sync without applying changes. | | **Apply Only** (`applyOnly`) | `boolean` | No (`false`) | Skip pre/post-sync hooks and sync waves. | | **Force Apply** (`forceApply`) | `boolean` | No (`false`) | Delete and recreate resources instead of patching. | | **Show Resource Progress** (`showResourceProgress`) | `boolean` | No (`false`) | Stream per-resource sync status to step logs. | | `autoConfirmPrune` | `boolean` | No (`false`) | Automatically approve a prune that is waiting for confirmation. Go to [Confirm resource pruning](#confirm-resource-pruning). | **Success criteria:** | Parameter | Type | Required | Description | | ---------------------------------------- | ---- | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------ | | **Success Criteria** (`successCriteria`) | enum | No (`syncSucceeded`) | `syncSucceeded` waits for Argo CD to report the sync complete. `syncInitiated` succeeds as soon as Argo CD accepts the sync request. | Go to [Success criteria](#success-criteria) to review when to use `syncInitiated` and which other settings it disables. **Health and timeout:** The following settings apply only when **Success Criteria** is **Sync Succeeded**. | Parameter | Type | Required | Description | | --------------------------------------------------- | --------------- | ------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Wait until healthy** (`waitTillHealthy`) | `boolean` | No (`false`) | Hold step until all synced apps reach `Healthy`. | | **Fail If Step Times Out** (`failOnTimeout`) | `boolean` | No (`false`) | When `waitTillHealthy: true`, fail the step if `Healthy` is not reached before timeout. | | **Degraded State Timeout** (`degradedStateTimeout`) | duration string | No (`"0"`) | Max time app may stay in `Degraded` before the step fails (for example, `"30s"`, `"5m"`). `"0"` disables early-exit. Only evaluated when `waitTillHealthy: true`. | {% hint style="warning" %} **Degraded State Timeout** `degradedStateTimeout` can fire during transient degraded states such as rolling updates where pods are briefly unavailable. Set conservatively or leave at `"0"`. {% endhint %} **Sync options** (`syncOptions`): | Parameter | Type | Required | Description | | ----------------------------------------------------------- | --------- | ----------------- | ----------------------------------------------------------------------- | | **Skip schema validation** (`skipSchemaValidation`) | `boolean` | No (`false`) | Skip Kubernetes schema validation before applying. | | **Auto-create namespace** (`autoCreateNamespace`) | `boolean` | No (`false`) | Create the destination namespace if it does not exist. | | **Prune resources at last** (`pruneResourcesAtLast`) | `boolean` | No (`false`) | Defer pruning until all other resources are applied. | | **Apply out-of-sync only** (`applyOutOfSyncOnly`) | `boolean` | No (`false`) | Only apply resources that differ from cluster state. | | **Replace resources** (`replaceResources`) | `boolean` | No (`false`) | Use `kubectl replace` instead of `apply`. | | **Server-side apply** (`serverSideApply`) | `boolean` | No (`false`) | Use Kubernetes server-side apply. | | **Respect ignore differences** (`respectIgnoreDifferences`) | `boolean` | No (`false`) | Honor the app's `ignoreDifferences` config during sync. | | **Prune propagation policy** (`prunePropagationPolicy`) | enum | No (`foreground`) | How pruned resources are deleted: `foreground`, `background`, `orphan`. | **Retry strategy** (`retryStrategy`): | Parameter | Type | Required | Description | | ---------------------------------------------- | --------------- | -------- | ---------------------------------------------------- | | **Limit** (`limit`) | `integer` (≥ 0) | No | Max retry attempts. | | **Base backoff** (`baseBackoffDuration`) | duration string | No | Initial wait before first retry (for example, `5s`). | | **Backoff factor** (`increaseBackoffByFactor`) | `integer` (≥ 0) | No | Multiply backoff by this factor on each retry. | | **Max backoff** (`maxBackoffDuration`) | duration string | No | Backoff ceiling (for example, `3m`). | *** ## Sync a multiple-sources application Go to [Support for Multiple Sources](/continuous-delivery/use-gitops/get-started/harness-cd-git-ops-quickstart.md#step-4-add-a-harness-gitops-application) to create a multi-source application. After you create an application with multiple sources, you can choose which source to sync with the application during the sync operation. By default, all sources are synced. Perform the following steps to sync a specific source: 1. Select the **Sync** button in the top right corner of the **Applications** page. 2. Under **Synchronizing application manifest from**, select the source tab from which you want to sync your application. 3. Select the **Sync Source** checkbox. The tab for the selected source, where the checkbox is enabled, is highlighted in green. *** ## Terminate sync To terminate an in-progress sync, go to the application for the syncing app and locate the **Terminate Sync** button in the top right corner of the UI. The **Terminate Sync** button replaces the **Sync** button when a sync is in progress. ![Terminate Sync button on a syncing application](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-891c2f555e28ca8dc404d6c858598bfc3cec5cee%2Fterminate-sync.png?alt=media) *** ## Bulk sync and refresh {% hint style="info" %} **Minimum agent version** Bulk Sync and Refresh require GitOps agent version 0.93 or higher. Confirm you have the correct agent version. An incorrect version can cause bulk syncs to time out after three minutes. {% endhint %} You can bulk sync or refresh your applications from the applications page. In your GitOps project, go to **Deployments** -> **GitOps** -> **Applications** to open the applications page. Select **Bulk Sync** in the top left to sync many applications at once, or select **Refresh** in the top right. The following screen appears for bulk sync, and a similar screen appears for refresh: ![Bulk Sync selection and options](https://3694223630-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fy1JhZ4oKIppwY7d5AhPj%2Fuploads%2Fgit-blob-5d31f4f761ab5d5ab492a61f11eaab21f6d61d89%2Fbulk-sync-reference.png?alt=media) In the top left you can select all the applications on the page, or you can select applications individually from the list. On the right you can modify your sync or refresh options. These options apply to all selected applications. After you select your applications and options, select **Bulk Sync** or **Bulk Refresh**. {% hint style="warning" %} **Batch size** The recommended batch size is 100 applications. To sync more than 100 applications, increase the `GITOPS_AGENT_NUM_PROCESSORS` value in the config by 1 for every additional 100 applications. For example, set it to 2 for 200 applications. {% endhint %} Required permissions for bulk operations: * **Bulk Sync**: You must have the `gitops app sync` permission. * **Bulk Refresh**: You must have the `gitops app view` permission. *** ## Sync notifications You can receive notifications for sync success or failure, out-of-sync drift, and health degradation. Go to [Centralised notification](https://developer.harness.io/docs/platform/use-harness-platform/notifications-alerts-and-banners/notifications/centralised-notification#gitops-application-notifications) to configure alerts for GitOps application events. *** ## Troubleshooting
Bulk sync times out after three minutes Confirm the GitOps agent version is 0.93 or higher. An older agent can cause bulk syncs to time out after three minutes. Also review batch size and `GITOPS_AGENT_NUM_PROCESSORS` if you sync more than 100 applications.
Configure Resources is not available Select **Application Name** in the GitOps Sync step. Resource filters are not available with **Application Regex**, **Application Labels**, or **Fetch Linked Apps**.
GitOps Sync step succeeds but the pipeline still fails If **Wait until healthy** and **Fail If Step Times Out** are enabled, the step can sync successfully and still fail when the application does not reach **Healthy** before timeout. Adjust timeout settings or disable **Fail If Step Times Out** when sync success alone is enough.
*** ## Next steps * [Harness GitOps quickstart](/continuous-delivery/use-gitops/get-started/harness-cd-git-ops-quickstart.md): Create GitOps applications, including multiple sources. * [Centralised notification](https://developer.harness.io/docs/platform/use-harness-platform/notifications-alerts-and-banners/notifications/centralised-notification#gitops-application-notifications): Configure sync and health alerts. * [Use Harness expressions in GitOps applications](/continuous-delivery/use-gitops/application/use-harness-expressions-in-gitops-applications.md): Parameterize GitOps application configuration. {% @harness-feedback/feedback %}