Argo CD v3.3.12: Git Fetch Depth and Clusterinformer Locks

Argo CD version v3.3.12 is now available as of June 18 2026. This patch release brings targeted bug fixes to the application controller and repo server components. The most critical change for operators running large scale deployments is the correction of shallow clone depth behavior during git fetch operations, which reduces network and memory overhead.

The full release notes and downloads are on the GitHub release page.

Argo CD architecture splits responsibilities between the application controller and the repo server. The repo server is responsible for cloning repositories, generating manifests, and returning the desired state. For organizations managing monorepos or repositories with extensive commit histories, performing a full git clone is prohibitively expensive. Operators configure the repo depth setting to instruct Argo CD to perform shallow clones, pulling only the most recent commits needed to determine state.

Prior to version v3.3.12, the underlying git functions gitSourceHasChanges and the general fetch routines failed to honor this repo depth configuration. When the setting was ignored, the repo server fell back to executing full clones. This behavior triggered excessive CPU utilization, rapid memory consumption, and increased network bandwidth usage on the repo server pods. In environments with hundreds of applications pointing to the same repository, this flaw could lead to out of memory kills and degraded sync performance. The fix applied in pull request 28065 ensures that these functions strictly respect the configured depth limit, restoring the intended shallow clone mechanics and stabilizing repo server resource consumption.

Argo CD determines application health and sync status by comparing the live Kubernetes cluster state against the manifests generated from git. This comparison relies on state normalization to ignore differences that do not affect the actual configuration, such as fields injected by external controllers or Kubernetes admission webhooks.

The status subresource in Kubernetes is entirely dynamic and reflects the current operational state rather than the desired configuration. Previously, the normalization logic did not properly exclude live status fields. This inclusion caused Argo CD to calculate false out of sync conditions whenever a controller updated a status field, triggering unnecessary reconciliation loops and flooding the Argo CD user interface with inaccurate state drift warnings. Pull request 28203 corrects this by explicitly stripping live status from the normalization pipeline, ensuring that only true configuration drift triggers an out of sync event.

Another edge case addressed in this patch involves the PromotionStrategy state machine. Users observed that applications would permanently hang in the Progressing state following a no op rehydration. When manifests are rehydrated but yield no actual changes, the strategy controller failed to advance the state. Pull request 28136 patches this logic defect, allowing the controller to recognize the no op condition and transition the application to a healthy state without manual intervention.

The application controller relies on a Kubernetes informer cache to monitor the state of resources across all registered destination clusters. The clusterinformer caches these objects locally to reduce load on the Kubernetes API server. In multi cluster deployments, the controller runs numerous worker goroutines that concurrently read from and write to this shared cache.

Without proper synchronization primitives, concurrent map access in Go results in fatal panics. Pull request 28313 introduces a dedicated mutex lock around the clusterinformer access paths. This thread safety enhancement eliminates race conditions during cluster registration, secret updates, and cache invalidation events. For platform teams operating Argo CD at scale across dozens of clusters, this lock guarantees application controller stability and prevents random pod restarts caused by concurrency panics.

Additionally, this release resolves an edge case in the bundled Dex identity provider integration. Argo CD uses Dex to federate authentication to external OpenID Connect and SAML providers. Users discovered that local Dex passwords containing a dollar sign were incorrectly parsed, causing login failures. The underlying parser likely interpreted the dollar sign as an environment variable expansion directive rather than a literal string character. Pull request 28198 updates the parsing logic to safely escape and process the dollar sign, restoring access for affected users.

While mostly invisible to end users, version v3.3.12 includes several improvements to the Argo CD continuous integration and end to end testing pipeline. The test suite now features an explicit test case to validate the behavior of a second sync operation when applied with different resource options immediately after an initial sync. This ensures that the sync engine correctly handles updated flags without retaining stale state.

The developers also fixed a resource leak in the test execution environment. Previously, Custom Resource Definitions created during test runs were not properly removed, leaving cluster pollution that could affect subsequent test reliability. The cleanup routines now correctly purge these Custom Resource Definitions. Finally, the continuous integration workflow bumped the Codecov action to version 7 to bypass a known GNU Privacy Guard signature verification issue.