# 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).