duocthu/infra/argocd/README.md

ArgoCD (GitOps deployment)

Deployment uses the team's existing ArgoCD instance (not self-hosted by this project) rather than a custom push-based CD pipeline. See docs/adr/0002-argocd-gitops.md for the rationale.

Flow

1. CI (infra/ci/github-actions/*-ci.yml) builds and pushes a container image per app on merge to main, then bumps that app's image tag in infra/helm/medical-chatbot/values-<env>.yaml (or a per-app values file) and pushes that commit back to the repo. CI never runs kubectl apply or helm upgrade directly.
2. ArgoCD (team-managed, pointed at this repo) watches infra/argocd/applications/<env>/ and infra/helm/medical-chatbot/, detects the values-file change, and syncs the cluster to match — this is the actual deploy step, owned by ArgoCD, not by our CI.
3. Promotion between environments (dev -> staging -> prod) is a Git operation (merge/PR that changes the target values file or image tag for that env), not a manual kubectl/helm command.

Files

• applications/dev/app.yaml, applications/staging/app.yaml, applications/prod/app.yaml — one ArgoCD Application CR per environment, each pointing at this repo + the infra/helm/medical-chatbot chart with that environment's values file.

TODO once the team's ArgoCD instance details are known

• Fill in spec.destination.server (target cluster API server / context name) in each app.yaml — currently a placeholder.
• Confirm which ArgoCD project (RBAC scoping) these Applications should belong to, instead of the placeholder default.
• Confirm the repo URL placeholder in each app.yaml once the GitHub repo exists (filled in as part of the initial scaffold commit/push).