feat: prepare the values for Argo CD v3.4.9 on argo-helm chart 10.2.2

[venkatamutyala]

Companion to the Kubernetes 1.35 platform upgrade (GlueOps/platform-helm-chart-platform#1498, CRDs in GlueOps/platform-crds#83 with the Argo CD pin at v3.4.9). Argo CD moves v3.2.12 -> v3.4.9 on argo-helm 9.3.7 -> 10.2.2 (10.2.2 is the last chart on the 3.4 line; it ships v3.4.6, so the image tag override this module already applies via argocd_app_version carries it to v3.4.9). The chart version itself is pinned by the consumer (terraform-module-cloud-multy-prerequisites), not here.

What this changes in argocd.yaml.tpl

Change	Why
IGNORE_FAILURE: "true" on the otel-extension installer env	chart >= 9.4.18 uses argocd-extension-installer v1.0.1, which exits non-zero when the tarball download fails and blocks argocd-server from starting. v0.0.9 always exited 0. This keeps the fail-open behaviour: a missing extension renders nothing.
global.networkPolicy.create: true made explicit, with a comment	chart 10.0.0 flipped the default to true as the fix for GHSA-47m3-95c7-g2g8 (repo-server reachable from any pod -> RCE). Pinning it means a future chart bump cannot flip it silently. Renders 5 NetworkPolicies: argocd-server allows all ingress, the three controllers allow only :metrics from any namespace, argocd-repo-server:8081 only from the argocd-* pods in the namespace; redis-ha gets none. Note: on the current chart 9.3.7 this already renders the same five policies, so applying this module version ahead of the chart bump brings the fix forward. Requires a CNI that enforces NetworkPolicy.
EXTENSION_URL moved to https://repo.gpkg.io/repository/raw-github/GlueOps/argo-cd-ui-extention/...	the same raw-github proxy pattern GlueKube uses for GitHub release assets; argocd-server no longer needs direct egress to github.com at startup. The proxy serves the tarball byte-identical to GitHub (sha256 compared).
server.ingress.hosts / paths removed	ignored since chart 6.0.0; the Ingress host comes from global.domain and the path defaults to /. Render unchanged.

README: CRDs come from platform-crds and must be applied --server-side (the ApplicationSet CRD exceeds the client-side-apply annotation limit since 3.3); example bumped to chart 10.2.2 / argocd_app_version = "v3.4.9".

Upstream 3.2 -> 3.4 review (summary; full report in the platform PR thread)

Nothing in argocd-cm, argocd-cmd-params-cm or argocd-rbac-cm that this module sets was renamed or removed; builtin RBAC policy and resource/action lists are byte-identical between v3.2.12 and v3.4.9; oidc.config, extension.config, server.enable.proxy.extension and --application-namespaces=* are unchanged. Behaviour changes that apply: Application health is Missing only when all resources are missing (3.4); 3.4.4 RBAC fix for apps-in-any-namespace (our development/* patterns still match both <project>/<app> and <project>/<ns>/<app>); bundled Helm 3.19.4 / Kustomize 5.8.1 in the repo-server (Kustomize helmCharts now gets namespace: propagated, so tenant Kustomize apps may show a one-time diff); go-oidc verifies signatures before claims (expired token + rotated key lands on the login page instead of auto-redirecting). CRDs v3.2.12 -> v3.4.9 are additive only, so applying them ahead of the controller is safe. Direct 3.2 -> 3.4 is supported by upstream.

Verification

• helm template chart 10.2.2 + v3.4.9, old tpl vs new tpl: the only diffs are the IGNORE_FAILURE env and the proxied EXTENSION_URL on the init container.
• Chart 9.3.7 + v3.2.12 vs chart 10.2.2 + v3.4.9 (old tpl): +5 NetworkPolicies, redis-ha 4.34.11 -> 4.38.0 (image bumps, sentinel quorum self-heal, probes on split-brain-fix; no selector changes), timeout.reconciliation.jitter: 60s added to argocd-cm (already the in-code default), installer image v0.0.9 -> v1.0.1. argocd-cmd-params-cm, argocd-rbac-cm, oidc.config, both Ingresses and all extraObjects unchanged.
• Images verified on the mirrors: quay.repo.gpkg.io/argoproj/argocd:v3.4.9, quay.repo.gpkg.io/argoprojlabs/argocd-extension-installer:v1.0.1, ecr.repo.gpkg.io/docker/library/haproxy:3.3.10-alpine, …/redis:8.2.3-alpine (the pull-through cache briefly auto-blocks after a 429; pre-pull before rollout).

Rollout order

1. platform-crds release with pin.argo-cd: v3.4.9, applied server-side (safe against the running 3.2.12).
2. Warm the mirror for the four images above.
3. Release this module; in the consumer bump the module ref, argocd_app_version = "v3.4.9", argocd_helm_chart_version = "10.2.2".
4. Expect rollouts of controller, server, repo-server, applicationset, notifications, redis-ha-server (3, rolling) and haproxy; no Redis flush needed; no Application migration.

🤖 Generated with Claude Code

https://claude.ai/code/session_01FSau4e6nS8Y7eM1nQHwq6k