argo-cd:
  # GKE counterpart of helm-overrides/k8s-admin-prd-ase1/argocd-admin-prd.
  #
  # Installed once by hand with `helm install argocd-admin-prd` (namespace
  # "argocd"), then manages itself through the argocd Application in
  # devops-infra-argo-config-gcp, whose nameOverride matches that release.
  global:
    image:
      tag: "v2.13.8"

  # SSO still deferred, same as the homelab.
  dex:
    enabled: false

  controller:
    replicas: 1
    resources:
      requests:
        cpu: 200m
        memory: 400Mi
      limits:
        cpu: 500m
        memory: 768Mi

  redis-ha:
    enabled: false
  redis:
    resources:
      requests:
        cpu: 50m
        memory: 64Mi
      limits:
        memory: 128Mi

  # repo-server does the manifest rendering (helm template per Application),
  # so it is the component that actually saturates when many apps sync at
  # once. Stateless, safe to run several behind its Service. With
  # autoscaling on, the chart omits `replicas` from the Deployment, so the
  # HPA and ArgoCD's own self-management do not fight over the count.
  #
  # CPU only. The chart's default also scales on memory, but a Go process
  # does not hand memory back promptly after a spike, so a memory target
  # scales up and then never scales down. Setting it to null removes it.
  repoServer:
    autoscaling:
      enabled: true
      minReplicas: 1
      maxReplicas: 3
      targetCPUUtilizationPercentage: 70
      targetMemoryUtilizationPercentage: null
    resources:
      requests:
        cpu: 100m
        memory: 256Mi
      limits:
        cpu: 300m
        memory: 512Mi

  # API/UI. Stateless, sessions live in Redis, so replicas are
  # interchangeable. Same CPU-only reasoning as repoServer above.
  server:
    autoscaling:
      enabled: true
      minReplicas: 1
      maxReplicas: 3
      targetCPUUtilizationPercentage: 70
      targetMemoryUtilizationPercentage: null
    extraArgs:
      - --insecure
    ingress:
      enabled: true
      ingressClassName: contour
      hostname: "argocd.35.238.248.203.nip.io"
    resources:
      requests:
        cpu: 50m
        memory: 128Mi
      limits:
        cpu: 200m
        memory: 256Mi

  applicationSet:
    enabled: false
  notifications:
    enabled: false

  configs:
    cm:
      url: "http://argocd.35.238.248.203.nip.io"
      timeout.reconciliation: 3m
      timeout.reconciliation.jitter: 60s
      # No Ingress health override, unlike the homelab: there Contour sat
      # behind hostPort, so nothing ever wrote an Ingress's load balancer
      # status. On GKE Envoy gets a real LoadBalancer Service and Contour
      # writes that status, so ArgoCD's built-in check works as intended.
      #
      # Scoped account for Jenkins' syncArgoApp step — same as the homelab.
      accounts.jenkins-ci: apiKey
      accounts.jenkins-ci.enabled: "true"
    rbac:
      policy.csv: |
        p, jenkins-ci, applications, sync, webapp/*, allow
        p, jenkins-ci, applications, get, webapp/*, allow
    # Reached over cluster DNS, never through Contour — which is what lets
    # Contour itself be ArgoCD-managed. The repos are private on this
    # public-facing Gitea, so ArgoCD reads them with a repo-creds Secret
    # (created at bootstrap, covering everything under gitadmin/), not
    # anonymously as in the homelab.
    repositories:
      devops-infra-helm-charts-gcp:
        url: http://gitea-http.gitea.svc.cluster.local:3000/gitadmin/devops-infra-helm-charts-gcp.git
      devops-infra-argo-config-gcp:
        url: http://gitea-http.gitea.svc.cluster.local:3000/gitadmin/devops-infra-argo-config-gcp.git