server.additionalApplications is silently dropped, blocking GitOps bootstrap
- Dominant language
- Go Template
- Stars
- 2.3k
- Forks
- 186
- Avg merge
- 3d 11h
- Merged PRs (30d)
- 66
Description
**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.:
```yaml
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: __
- 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 `Secret`s 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.
Contributor guide
Research direction
Read helmfile.d/snippets/common.gotmpl and helmfile.d/snippets/templates.gotmpl to trace the _rawValues passthrough, then inspect charts/argocd/Chart.yaml, charts/argocd/README.md:650-658, and charts/argocd/templates/. Compare this with the absence of charts/argocd-apps and an argocd-apps release in helmfile.d/. Done means a supported install-time values path creates the requested Application/AppProject resources or rejects the removed key instead of silently ignoring it.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- kubernetes
- Domain
- devops, infrastructure
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100