clusterSpec:
  # "k8s-admin-prd-ase1" only resolved in the fleet because that name was
  # registered as an external cluster in the hub ArgoCD's cluster list.
  # There's no hub here — one ArgoCD, running on the cluster it manages —
  # so this has to be the built-in local-cluster alias instead.
  destination:
    server: ""
    name: "in-cluster"

argocdSpec:
  # Was argocd-admin (a separate hub namespace in the fleet's two-tier
  # setup). Single ArgoCD instance here, so Application objects live in
  # the same namespace as ArgoCD itself — see claude.md.
  namespace: argocd

teamSpec:
  devops:
    source:
      repoURL: http://gitea.192.168.1.7.nip.io/mukul/devops-infra-helm-charts.git
      targetRevision: main
      path: helm-templates
      valueFiles: ../../helm-overrides/k8s-admin-prd-ase1
    labels:
      bu: infra
      team: devops
      env: prd
      cluster: k8s-admin-prd-ase1

appSpec:
  - name: argocd
    nameOverride: argocd-admin-prd
    namespace: argocd
    chartDir: argo-cd
    valuesDir: argocd-admin-prd
  - name: gitea
    # Adopting the already-running standalone install (helm release
    # "gitea" in namespace "gitea", from deploy_gitea.sh) rather than
    # deploying a second one — nameOverride pins the rendered
    # Application's name (and therefore the Helm release name Argo
    # renders with) to match those existing object names exactly.
    nameOverride: gitea
    namespace: gitea
    chartDir: gitea
    valuesDir: gitea
    # NOT using the Application-wide `replace: true` here anymore — it
    # forces a full PUT of every resource this Application renders, and a
    # bound PVC's spec is immutable (volumeName/storageClassName get
    # filled in by the provisioner after binding; a PUT that omits them
    # looks like clearing them, which the API correctly refuses). The
    # Deployment-only fix now lives as a per-resource sync-option
    # annotation in helm-overrides/k8s-admin-prd-ase1/gitea/custom-values.yaml
    # (deployment.annotations), which only Replaces the Deployment.
  - name: vault
    # Adopting the running production-mode Vault (helm release "vault" in
    # namespace "vault", chart 0.34.1 — see helm-templates/vault/Chart.yaml).
    # It's already initialized and unsealed; this Application only manages
    # Vault's Deployment/config, never its data or seal state. Review the
    # first diff carefully before syncing — this is the highest-consequence
    # adoption in this repo so far.
    nameOverride: vault
    namespace: vault
    chartDir: vault
    valuesDir: vault
  - name: contour
    # Adopting the running ingress (helm release "contour" in namespace
    # "projectcontour", chart 0.7.0 — the OFFICIAL projectcontour chart,
    # not the Bitnami one that used to be wired up as helm-templates/contour
    # — see the note in that Chart.yaml and claude.md issue #4). This is
    # the ingress path for every other Application in this repo — review
    # the diff before syncing, same caution as vault.
    nameOverride: contour
    namespace: projectcontour
    chartDir: contour
    valuesDir: contour
  - name: external-secrets
    # Correction from an earlier version of this file: "no nameOverride
    # needed" was wrong. Without one, the Application (and therefore the
    # Helm release name the chart templates with) becomes
    # "external-secrets-admin-prd" — so the controller's ServiceAccount
    # actually ends up named external-secrets-admin-prd, not
    # external-secrets. secretstores/vault-backend.yaml's
    # serviceAccountRef assumes the plain name, and Vault's role was bound
    # to bound_service_account_names=external-secrets — both need this
    # pinned name to match.
    nameOverride: external-secrets
    namespace: external-secrets
    chartDir: external-secrets
    valuesDir: external-secrets
    # ClusterSecretStore's CRD (large embedded OpenAPI schema) exceeds the
    # 256KiB last-applied-configuration annotation limit on a normal
    # client-side apply. SSA sidesteps it entirely — see the note in
    # generic-argo-apps-chart's template.
    serverSideApply: true
  - name: jenkins
    # Fresh install, but pinning nameOverride anyway — learned from
    # external-secrets that skipping it produces
    # "jenkins-admin-prd"-suffixed resource names, which
    # jenkins-admin-credentials (the ExternalSecret, namespace "jenkins")
    # doesn't need to care about, but keeps naming predictable and
    # consistent with every other app here regardless.
    nameOverride: jenkins
    namespace: jenkins
    chartDir: jenkins
    valuesDir: jenkins
  - name: harbor
    # Fresh install (helm list -n harbor came back empty despite claude.md
    # saying otherwise). nameOverride pinned for the same predictability
    # reason as jenkins — rendered object names all end up prefixed with
    # this (harbor-core, harbor-registry, etc.), which is also what
    # Jenkins needs to reference for internal image pushes
    # (harbor-core.harbor.svc.cluster.local).
    nameOverride: harbor
    namespace: harbor
    chartDir: harbor
    valuesDir: harbor
  - name: postgresql
    # Backs toolshed's control plane. Own namespace rather than living
    # inside toolshed, so it is addressed over cluster DNS like any other
    # platform component and outlives whatever consumes it:
    #   postgresql.postgres.svc.cluster.local:5432
    #
    # nameOverride pinned for the same reason as everything else here —
    # without it the rendered Application (and therefore the Helm release
    # name, and therefore every object name) becomes
    # "postgresql-admin-prd-prd".
    #
    # Hand-written chart, not Bitnami's: that registry has been actively
    # unstable (infra issue #4) and PostgreSQL ships no official chart.
    # Requires secretstores/toolshed-postgres-credentials.yaml to have
    # synced first — the pod cannot start without the Secret.
    nameOverride: postgresql
    namespace: postgres
    chartDir: postgresql
    valuesDir: postgresql
  - name: prometheus
    # Server only — see custom-values.yaml for exactly why the chart's
    # alertmanager/kube-state-metrics/node-exporter/pushgateway subcharts
    # are all disabled, and why that is enough for what consumes this:
    # toolshed's per-app CPU/memory metrics (docs/PRODUCT-ARCHITECTURE.md
    # step 5), read straight from the built-in kubernetes-nodes-cadvisor
    # scrape job.
    #
    # Vendored official chart (prometheus-community/prometheus), not
    # hand-written — unlike postgresql, this one has a real official
    # chart, and Contour/ArgoCD/Vault/Gitea/Harbor/Jenkins already use
    # this same vendor-the-official-chart pattern rather than reinventing
    # RBAC and Kubernetes service discovery by hand.
    #
    # nameOverride pinned to exactly "prometheus" for the same reason as
    # postgresql/gitea above — without it every rendered object name
    # becomes "prometheus-admin-prd-prd" instead. This one matters more
    # than most: the chart's server Service renders as
    # "<release-name>-server", so pinning the release name to "prometheus"
    # is what makes it "prometheus-server" — the exact hostname toolshed's
    # PROMETHEUS_URL already points at
    # (prometheus-server.monitoring.svc.cluster.local), seeded before this
    # existed so the connection would already be correct the day it did.
    nameOverride: prometheus
    namespace: monitoring
    chartDir: prometheus
    valuesDir: prometheus