Argo CD 3.3.4
Argo CD 3.3.4
Section titled “Argo CD 3.3.4”FractalOps runs Argo CD v3.3.4. Investigation date: 2026-07-15.
Supported Path
Section titled “Supported Path”- Assembly owns Application and AppProject manifests. Runtime control resolves
each Application from
<metadata.name>.application.yaml, restores it with server-side apply, requests a hard refresh, then syncs the compared revision. - The self Application owns child definitions, not child runtime health. The
runtime chart adds
argocd.argoproj.io/ignore-healthcheck: "true"to immediate child Application resources. Each child Application still reports and proves its own sync and health independently. - Runtime control uses the Kubernetes API only. Its service account can get and patch Applications but cannot read Secrets or create/delete Applications.
Operational Traps
Section titled “Operational Traps”- Argo permits singular
spec.sourceor pluralspec.sources, never both. Server-side apply can retain the old shape when another field manager owns it. Runtime control therefore performs one resource-version-fenced JSON Patch that removes the old shape and adds the declared shape before restoring SSA ownership. - A hard refresh is asynchronous. Wait until Argo removes
argocd.argoproj.io/refreshbefore reading the compared revision. - Argo CD
v3.3.4has noapplications/statussubresource. Do not grant or call it; main-resource patching is the supported control path in this cluster. - Parent health must not become a proxy for every child workload. Without the native ignore-health annotation, app-of-apps sync can wait indefinitely on an unrelated child while all child definitions are already applied.
Verification
Section titled “Verification”pnpm test:runtime-argocdnode --test .github/workflows/runtime-control.test.mjsAuthoritative references: Argo CD 3.3.4 child health guidance, Argo CD 3.3.4 health controller, and Argo CD 3.3.4 source.