Files
devops-infra-helm-charts-gcp/claude/00-overview.md
T
2026-08-26 03:39:42 +05:30

4.8 KiB
Raw Blame History

Per AI Blitz Plan §claude. Layer: 1. Repo: devops-infra-helm-charts.

00 — Overview

Why this repo exists

devops-infra-helm-charts is the GitOps source-of-truth for what infrastructure tooling runs on Meesho's GKE fleet, where, and with what values. It is one of two repos that together compose the platform's deploy plane:

  • This repo — values + cached/forked charts. Answers "what does cluster X's Argo CD agent stack look like?"
  • Sister repoMeesho/devops-infra-argo-config — Argo Application / ApplicationSet manifests. Answers "which cluster pulls which path from the values repo, with what sync policy?"

A merge to main here is a deploy event: every Argo CD instance whose Application points at a touched path will reconcile, on its own cadence (auto-sync) or on a human Sync click (manual-sync — the prod default).

See ../wiki/entities/DevOps Infra Helm Charts.md for the conceptual model and ../docs/architecture.md for the full deploy lifecycle.

What's in it

Top-level Role
helm-templates/<chart>/ 74 cached or forked upstream charts (Argo CD, Contour, VictoriaMetrics, Mimir, Loki, Tempo, Vault, Keda, Kyverno, Jenkins, JFrog, Grafana…).
helm-overrides/<cluster>/<app>/custom-values.yaml Per-cluster × per-app Helm values. Edited daily.
helm-overrides/<cluster>/<app>/<extra>.yaml Raw manifests applied alongside the Helm release (compute-class definitions, external-DNS records, etc.).
manifests/storageclass/, manifests/priorityclass/<cluster>/ Cluster-wide singletons. High blast radius.
manifests/{jenkins,jfrog}-…/{dev,prd}/ Per-env one-shot PV/PVC manifests.
pre-commit-scripts/ TruffleHog (active, blocking); CAC + Yaak (no-op here).
post-commit-scripts/ Cursor AI commit metric collector (background).
repository.yaml Owners, auto-managed by registry-bootstrap.
contour-nodeselector-tolerations-summary.md Per-cluster Contour scheduling matrix.

Detailed walkthrough in ./01-repo-structure.md.

What's NOT in it

  • Argo CD Application / ApplicationSet manifests — those live in the sister repo. See ../docs/global/coding-guidelines/argocd.md.
  • Application / service code — lives in service repos.
  • Workload-cluster kubectl apply operations — that's incident response, not authoring.
  • Production endpoint probes (*.meesho.int, *.mrouter.int, *.meeshogcp.in) — never call from an agent. See ../docs/global/SANCTITY_RULES.md.

How a change reaches a cluster

  1. Branch off main.
  2. Edit a single helm-overrides/<cluster>/<app>/custom-values.yaml.
  3. Local dry-run: helm template <release> helm-templates/<chart> -f helm-overrides/<cluster>/<app>/custom-values.yaml.
  4. Commit — TruffleHog runs (blocking). Never --no-verify.
  5. Open a PR. Reviewer is the first safety gate.
  6. Merge to main.
  7. Argo CD on the target cluster either auto-reconciles (low-risk leaves) or waits for a human Sync click (prod infra default).

That click is the second safety gate. The combined property (reviewer + Sync) is the system's safety floor while a tool-mediated edit path (helm-values-tool) is still being built.

See ./05-deploy-lifecycle.md for the full flow with failure modes, and ./08-pre-commit-and-hooks.md for the hook details.

Layer classification

This repo is Layer 1 — Agent-Writable (config repo). Most edits are agent-eligible via PR. Several operations are Layer 1 high-risk or Layer 3 (refuse). The full mapping is in the root CLAUDE.md Layer constraint summary table; the agent-facing summary is ../docs/global/AGENT_BOUNDARIES.md and ../docs/global/SANCTITY_RULES.md.

Where to go next