server.additionalApplications is silently dropped, blocking GitOps bootstrap

[aweingarten]

Describe the bug:
Setting Argo CD Applications via apps.argocd._rawValues.server.additionalApplications is silently ignored — the values are accepted and merged into the argo-cd chart, but no Application is ever created, with no error or warning.

This matters because it is the only install-time mechanism for apl to seed an Argo CD Application. We use it for the single most important bootstrap step: have apl seed one root "app-of-apps" Application that points Argo CD at our GitOps repo. That one Application is what makes Argo CD start reconciling the entire platform from Git (foundation NetworkPolicies, AppProjects, the ESO ClusterSecretStore, and all per-component Applications). Without it, apl finishes its helmfile, Argo CD is running — and then sits idle: it has no idea our GitOps tree exists, so ESO CRDs, foundation NetworkPolicies, AppProjects, etc. never appear.

Root cause: apl-core bundles argo-cd chart 9.5.21 (charts/argocd, appVersion v3.4.3), and that chart major removed server.additionalApplications/server.additionalProjects (its README: "moved to argocd-apps"). apl-core does not bundle or deploy the replacement argocd-apps chart, and nothing in values/argocd/*.gotmpl re-implements it. So there is currently no working values path to declare additional Argo CD Applications/Projects through apl — the _rawValues passthrough merges the key faithfully, but the destination chart no longer reads it.

To Reproduce
Steps to reproduce the behavior:

1. Install apl via the apl chart (apl-operator), letting its helmfile install argo-cd (chart 9.5.21).
2. In your values, set an Application under the documented passthrough, e.g.:

   apps:
     argocd:
       _rawValues:
         server:
           additionalApplications:
             - name: guestbook
               namespace: argocd
               project: default
               source: { repoURL: https://github.com/argoproj/argocd-example-apps, path: guestbook, targetRevision: HEAD }
               destination: { server: https://kubernetes.default.svc, namespace: guestbook }

3. Let apl-operator run the helmfile to completion.
4. kubectl -n argocd get applications → the guestbook Application is absent. The rendered argo-cd values contain server.additionalApplications, but no resource is produced and no error is surfaced.

Expected behavior:
A supported, install-time, values-native way for apl to seed Argo CD Application/AppProject resources — so an integrator can point Argo CD at their own GitOps repo with a single root Application, declared entirely in apl values. Concretely, either: (a) apps.argocd._rawValues.server.additionalApplications keeps creating the declared Applications/Projects (back-compat), or (b) apl bundles/deploys argocd-apps and exposes an equivalent key. Whichever path, an unsupported/removed key must not be silently accepted — it should be honored or rejected, not a no-op.

The install-time requirement is essential: at bootstrap, Argo CD does not yet exist to reconcile an Application CR applied from outside, so the seed Application has to be rendered by the argo-cd chart itself, present the moment Argo CD starts. server.additionalApplications was exactly that; nothing else in apl currently fills the gap.

Screenshots: N/A (CLI/declarative — see the empty kubectl get applications output in step 4).

Cluster(s):

• Cloud: Linode / Akamai (LKE-E)
• Cluster: platform support-services (reproducible on any fresh cluster)

Versions: (seen in console's /settings)

• Core Version: <your pinned apl-core version — repro traced on main, package version 6.0.0>
• Console Version: N/A
• API version: N/A
• Bundled sub-chart (root cause): argo-cd 9.5.21, appVersion v3.4.3 (charts/argocd/Chart.yaml)

Desktop: N/A (not a UI/browser issue)

Smartphone: N/A

Additional context:

Why we need apps.argocd._rawValues.server.additionalApplications specifically:

• It closes the GitOps bootstrap gap. apl installs Argo CD but offers no values-native way to tell that Argo CD about the integrator's own repo. One seeded app-of-apps Application is the entire handoff: from it, Argo CD reconciles the whole platform tree (foundation NetworkPolicies, AppProjects, ESO ClusterSecretStore, per-component Applications) from Git. One value bootstraps everything else.
• It's the only mechanism that works at install time. The seed Application must exist before/at the moment Argo CD starts — there's no running Argo CD yet to reconcile a CR applied afterward. server.additionalApplications is rendered by the argo-cd chart during its own install, so there's no external actor and no ordering race. Removing it leaves no in-chart path.
• The alternative is exactly what a GitOps platform should eliminate. Without it, we must push the root Application + AppProject + Argo CD repository-credential Secrets imperatively from outside the cluster (Terraform/CI holding a kubeconfig and PATs, with a CRD-wait that races apl-operator's helmfile installing argo-cd). That re-introduces out-of-band, kubeconfig-holding bootstrap on top of a platform whose whole value proposition is in-cluster GitOps reconciliation.

Root-cause evidence in apl-core main: helmfile.d/snippets/common.gotmpl:7 + helmfile.d/snippets/templates.gotmpl:2-6 (the _rawValues passthrough works and targets ../charts/argocd); charts/argocd/Chart.yaml (argo-cd 9.5.21); charts/argocd/README.md:650-658 (the removal/migration note); no charts/argocd-apps and no argocd-apps release in helmfile.d/; grep additionalApplications charts/argocd/templates/ returns nothing.

[aweingarten]

Related scope: the seed Application also needs its repo credentials seeded from values

This GitOps-bootstrap seam has a second half worth tracking alongside the additionalApplications fix. Even once apl can seed the root app-of-apps Application, that Application can't sync until Argo CD holds the repository credentials to authenticate to its source — and there's currently no values-native way for apl to seed those either.

At bootstrap Argo CD needs:

• the values / GitOps repo HTTPS credential (a repository-type Secret in argocd). apl already receives this PAT as otomi.git.password and may create its own repo Secret, but that isn't something we can rely on for the repo our root Application points at;
• credentials for any additional repositories (e.g. a separate apps repo); and
• OCI / ghcr.io pull credentials for private first-party Helm charts, which Argo CD needs at the very first sync wave.

None of these can be ESO-sourced at bootstrap: Argo CD needs them before the External Secrets Operator is installed (ESO comes later in the same helmfile). So today we push the repository/OCI Secrets imperatively from outside the cluster (Terraform kubectl_manifest, server-side apply, racing apl-operator's helmfile) — alongside the root Application itself.

Ask (complements the additionalApplications fix): a values-native way for apl to seed the Argo CD repositories/credentials during bootstrap — git HTTPS and OCI/ghcr.io. Unlike additionalApplications, the bundled argo-cd chart still supports configs.repositories and configs.credentialTemplates, so this may already be expressible through the existing apps.argocd._rawValues.configs.* passthrough — worth confirming, and if so just documenting it as the supported path; if not, wiring it the same way the values-repo Secret is handled.

With both halves, the entire Argo CD handoff (root Application + the repo/registry creds it authenticates with) is declared in apl values, and no integrator has to hold a kubeconfig + PATs to bootstrap GitOps.

[j-zimnowoda]

Hi @aweingarten,
The apl helm chart is only meant for bootstrapping the App platform.
Seeding application could be solved by seeding the values repo and installing the App Platform with BYO git feature enabled (available from v6.0.0)