Mukul SharmaandClaude Opus 5
bf814854fd
toolshed can now run a one-off command against an app — a migration, a seed, a backfill — in a throwaway Job built from the app's own image with its own configuration (internal/deploy.Client.RunCommand). It exists because a user with a provisioned database otherwise has no way to reach it: the operator can exec into the Postgres pod, a user cannot, and the premise is that nobody needs kubectl. Without this the deployer gets "forbidden" the moment anyone runs one — the two-repositories drift internal/deploy/kubernetes.go's own package doc warns about, and the third feature in a row to need both copies changed together. Delete is included because the Job is removed once its output has been captured into the run record; without it they would accumulate one per command forever. Notably absent is pods/exec, which an exec-into-the- running-pod design would have required — a far more dangerous grant on the one credential here whose compromise means the cluster, and one reason the Job approach was chosen over it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Wajog7nELA3i8JWTjxYGHF
devops-infra-argo-config
GitOps control plane for infrastructure tooling across Meesho's Kubernetes fleet.
This repo manages ArgoCD Application resources for every infrastructure tool (Contour, VictoriaMetrics, Grafana, Kyverno, KEDA, external-secrets, Vault, etc.) deployed across ~19 clusters. It uses an App-of-Applications pattern: one parent Application per cluster renders child Applications from a appSpec[] list via a generic Helm chart.
Each environment tracks a dedicated branch — merging to that branch triggers immediate ArgoCD auto-sync with no staging gate:
| Environment | Branch |
|---|---|
| Production (prd) | main |
| Staging (stg) | develop |
| Integration (int) | pre-prod |
How it works
incubator/<env>/<cluster>.yaml ← Parent Application (one per cluster)
└── points at generic-argo-apps-chart/ + values/<env>/<cluster>-values.yaml
└── renders one child Application per appSpec[] entry
└── sources charts + overrides from devops-infra-helm-charts
Directory structure
| Directory | Purpose |
|---|---|
incubator/<env>/ |
Parent ArgoCD Application YAML, one per cluster |
values/<env>/ |
Values files defining which tools deploy per cluster |
generic-argo-apps-chart/ |
Helm chart that renders child Applications from appSpec[] |
projects/ |
ArgoCD AppProject definitions (sre, sec) |
external-name-service-*/ |
Cross-cluster DNS routing (ExternalName / MCS topology) |
docs/ |
Agent-facing operational documentation |
skills/ |
Parameterized agent tasks for common operations |
wiki/ |
Architecture decisions and entity pages |
Getting started
- Agents: Read CLAUDE.md first.
- New team members: Read index.md for full navigation.
- PR reviewers: Check docs/global/coding-guidelines/infra-argo.md.
Common operations
| Task | Procedure |
|---|---|
| Add a tool to a cluster | docs/platform/procedures/add-tool-to-cluster.md |
| Upgrade a chart version | docs/platform/procedures/upgrade-chart-version.md |
| Onboard a new cluster | docs/platform/procedures/add-new-cluster.md |
| Roll out a tool fleet-wide | docs/platform/procedures/fleet-wide-tool-rollout.md |
| Debug sync failure | docs/platform/runbooks/argocd-sync-failure.md |
| Debug Helm render error | docs/platform/runbooks/render-failure.md |
| Find values inconsistencies across clusters | docs/platform/runbooks/values-drift.md |
| Debug stuck deployment | docs/platform/runbooks/deployment-stuck.md |
Sister repos
devops-infra-helm-charts— Helm charts andcustom-values.yamloverrides. EveryappSpec[].chartDirandvaluesDirmust exist here.devops-argo-config— Same pattern for service/application workloads (not infra tooling).