cicd-pipelinelisted

# CI/CD pipeline — GitHub Actions, Docker, Kubernetes Build one immutable, signed image in CI; promote that exact image by digest through environments in CD, each stage gated by checks and — for production — a GitHub Environment approval. Details differ per app; the sequence, the boundaries and the failure modes do not. - **CI/CD** — GitHub Actions. **Registry** — GHCR (`ghcr.io/<org>/<app>`). **Build** — `docker buildx`. - **Deploy target** — a Kubernetes cluster (Deployment + Service + Ingress, via Helm or Kustomize). A single-host Docker Compose target is the lightweight option. ## Reference architecture - **Delivery config separate from app code** — a `deploy/` folder or a dedicated repo. Reason: different change cadence and review rules. It holds the workflows and per-environment values. - **Build once, promote by digest.** One image per release candidate, identified by content digest (`@sha256:…`). The same digest flows staging → production — never rebuilt or re-tagged per environment. Tag with the version (`X.Y.Z`), pin by digest in every manifest. Environment is a deploy-time input. - **Promotion, not branches.** Trunk-based: one `main`, every merge is a release candidate, promoted through workflow stages gated by tests, policy and approvals. Environment chosen by a workflow input — one parameterized workflow, not drifting copies. *(Branch-per-environment works too; map the stages onto branches.)* - **Keyless auth.** Workflows reach the cluster and cloud APIs via