Feature Summary

Migrate --deployer argocd to the uniform numbered local-chart layout introduced by sub-issue 1. The branching rule for Application shape is the same as deploy.sh's: Chart.yaml presence in NNN-<name>/ → path-based single-source Application; absence → today's multi-source upstream-ref Application.

Parent: #516. Depends on the base format library (sub-issue 1) and the --vendor-charts flag (sub-issue 2).

Problem / Use Case

Once the base format exists and --vendor-charts is available, --deployer argocd should consume the same layout as --deployer helm — otherwise we've left "format, not deployer" half-done. The base format's Alt B pattern (mixed components emit primary + injected -post folders in sub-issue 1) eliminates the mixed-component special case entirely — every folder follows the simple "Chart.yaml present → local chart; absent → upstream ref" rule.

The goal is zero breaking change for current --deployer argocd users: today's multi-source Application shape is preserved wherever Chart.yaml is absent.

Proposed Solution

Branching rule: Chart.yaml presence in NNN-<name>/ → path-based single-source Application (spec.source.repoURL: <user-git>, spec.source.path: NNN-<name>). Absence → today's multi-source shape (source[0] upstream Helm repo, source[1] values git ref).

Per-case behavior:

• Wrapped Kustomize / raw-manifest-only (Chart.yaml always present after sub-issue 1): single-source path-based Application.
  • Today's argocd Kustomize Application is already single-source — shape-preserving.
  • Raw-manifest-only is a fix-forward: today's argocd deployer silently drops ComponentManifests (verified: bundler.go:301-314 constructs the argocd Generator without ComponentManifests). With sub-issue 1's chart-wrapping of raw manifests, these Applications now install successfully via the wrapped chart. Previously broken → now working.
• Pure Helm, non-vendored (no Chart.yaml): keep today's multi-source Application unchanged. Zero change for current users.
• Pure Helm, vendored (Chart.yaml present): path-based single-source Application. Argo's repo server reads local chart bytes; no helm dependency update / no helm.enableDependencyUpdate surface.
• Mixed Helm + raw manifests, non-vendored (primary + injected -post folder from sub-issue 1): full fix-forward — each folder gets a normal Application via the Chart.yaml-presence rule. Primary: multi-source upstream ref (today's shape, unchanged). Injected -post: single-source path-based, installs the wrapped-manifests chart. Sync-wave on the -post Application is primary's wave + 1 so ordering is preserved. Today's silent-drop of ComponentManifests becomes deployed manifests as a side effect of the Alt B layout — no warning needed.

App-of-apps root Application (spec.source.directory.include='*/application.yaml', recurse) keeps working — the recurse pattern doesn't care about numbering.

Success Criteria

• Branching on Chart.yaml presence produces the right Application shape across all per-component cases.
• Existing non-vendored --deployer argocd users see no behavior change for pure-Helm cases (multi-source Applications preserved).
• Raw-manifest-only components install successfully under --deployer argocd (previously silently broken).
• Mixed components (primary + -post folders) emit two correctly-ordered Applications; sync-wave on the -post is primary + 1. Raw manifests now deploy under --deployer argocd.
• Under --vendor-charts, pure-Helm components get path-based single-source Applications.
• KWOK e2e against --deployer argocd passes (non-vendored + vendored paths covered), including a mixed component.
• make qualify clean; test coverage gate satisfied.
• docs/user/cli-reference.md updated.

Alternatives Considered

• Always emit path-based single-source (require helm.enableDependencyUpdate for non-vendored Helm). Rejected: introduces a version-dependent Argo CD surface we can sidestep.
• Preserve today's silent-drop for mixed components with a warning. Rejected: sub-issue 1's Alt B layout (primary + -post folders) lets us fix the drop entirely at zero cost to argocd, so warn-and-drop would be a regression vs what's available.
• Umbrella Chart.yaml with dependencies: for mixed components in non-vendored mode. Rejected: reintroduces helm dependency update at deploy time and re-exposes helm.enableDependencyUpdate for that subset.

Component

Bundlers (gpu-operator, network-operator, etc.)

Priority

Important (would improve my workflow)

Compatibility / Breaking Changes

Minimal. Non-vendored --deployer argocd users see only file-path renames in the generated bundle (auto-regenerated on every aicr bundle; no migration). Application shape unchanged for them. Vendored users see single-source path-based Applications — documented in PR + release notes.

Operational Considerations

• Raw-manifest-only components newly work under argocd — operators should expect those manifests to now appear in target clusters after the upgrade.
• Mixed components (e.g. gpu-operator) newly have their raw manifests deployed under argocd via the injected -post Application. Same expectation as above.
• Parallel installs via a needs: release-dependency graph are out of scope here — tracked under #632 for the helmfile deployer, which has native needs: semantics.

Are you willing to contribute?

Maybe, with guidance