added files

2026-08-26 02:02:24 +05:30
parent 58ee8a276a
commit 3419cfba0c
200 changed files with 22132 additions and 0 deletions
@@ -0,0 +1,49 @@
+<!-- m-wiki: type=concept slug=cac-validation topic=policy base-sha=28f54cf7bef9 generated-at=2026-05-12T00:00:00+00:00 sources=[] -->
+
+> Generated 2026-05-12 at base-sha 28f54cf7bef9. Type: concept. 0 sources.
+
+# CAC (Config-as-Code) Validation
+
+CAC validation runs `resources/com/meesho/validate_configs_v2.py` on PR builds for repos opted in via the `ValidateCacConfig` whitelist. It validates application YAML configs against a schema to catch misconfigurations before they reach staging.
+
+## Where it applies in this repo
+
+`src/com/meesho/utilities/constructParam.groovy:ValidateCacConfigForRepo`
+
+`resources/com/meesho/validate_configs_v2.py`
+
+**Trigger condition:**
+- Build is a PR build (`env.CHANGE_ID` is set).
+- `ValidateCacConfigForRepo(config.ValidateConfig, repo_name)` returns `true`.
+  - Either the repo is in the `ValidateCacConfig.yaml` whitelist, OR
+  - `config.yaml` has `ValidateConfig: true`.
+
+**What gets validated:**
+The script reads `configs/<module>/application-*.yml` files from the service repo and checks them against the CAC schema. Validation errors fail the PR build — the commit cannot be merged until the config is corrected.
+
+Used primarily by Go and Maven services. Node, Python, and PHP builders do not call CAC validation.
+
+## Why this design
+
+Application config files (`application-stg.yml`, `application-prd.yml`) define Spring/Gin/etc. runtime config. A typo or wrong data type in these files doesn't fail compilation but causes a runtime crash after deployment. CAC validation catches these at PR time — when the feedback loop is cheapest.
+
+The validation script is bundled as a library resource (`resources/com/meesho/validate_configs_v2.py`) so it travels with the library version rather than requiring a separate checkout.
+
+## Related
+
+- [Whitelist system](whitelist-system.md) — ValidateCacConfig whitelist that gates this
+- [Config policy](../06-CONFIG-POLICY.md) — constructParam context
+
+## Sources
+
+(no raw/ sources at bootstrap)
+
+## Notes
+
+<!-- Anything below is human-owned. wiki-init never reads or modifies content under this heading. -->
+
+---
+
+[← Wiki index](../../index.md)
+
+<!-- atomic: keep this page ≤600 words. New scope → new concept page that builds on this one. Do not append paragraphs here. -->
@@ -0,0 +1,50 @@
+<!-- m-wiki: type=concept slug=multi-tenancy topic=policy base-sha=28f54cf7bef9 generated-at=2026-05-12T00:00:00+00:00 sources=[] -->
+
+> Generated 2026-05-12 at base-sha 28f54cf7bef9. Type: concept. 0 sources.
+
+# Multi-Tenancy: BU and Team Mapping
+
+Meesho's CI/CD pipeline partitions services by business unit (BU) and team. `buTeamMapping.groovy` translates full BU/team names to short initials used in Helm chart paths, Docker image paths, and ArgoCD namespaces.
+
+## Where it applies in this repo
+
+`src/com/meesho/utilities/buTeamMapping.groovy`
+
+**`get_bu_initials(bu)`** maps full BU names to short abbreviations:
+- `supply` → `su`, `demand` → `de`, `central` → `ce`, `dataengg` → `da`, `datascience` → `ds`, `mcache` → `mc`, `infra` → `in`
+
+**`get_team_initials(team)`** maps team slug to a short initial (typically first 2-4 chars of the slug).
+
+These initials are used to construct:
+- Helm chart paths: `devops-helm-charts/<helmChartsPath>/<buIni>/<teamIni>/<app_name>/`
+- ArgoCD app names: `<env>-<teamIni>-<app_name>` (or similar)
+- ArgoCD namespace: `argocd-<bu>-prd` (GCP prd)
+- GCPProject: `meesho-<bu>-prd-0622` (from `constructParam.run()`)
+
+**`config.yaml` fields:**
+- `bu`: must be one of the valid BU values (`supply`, `demand`, `central`, `dataengg`, `datascience`, `mcache`, `infra`).
+- `team`: must match a known team slug in `buTeamMapping`.
+- `validateBuTeam.groovy` in `src/com/meesho/stages/` validates the BU/team combination before deployment.
+
+## Why this design
+
+Multi-tenancy isolation is enforced structurally — a `supply` service's Helm values live in a separate directory from `demand`. If a service mis-declares its BU, its Helm charts and ArgoCD apps land in the wrong directory hierarchy, which causes the deploy to fail or overwrite another team's app. The initials mapping abstracts this from individual service owners.
+
+## Related
+
+- [Config policy](../06-CONFIG-POLICY.md) — bu/team are required fields in config.yaml
+- [Deploy ArgoCD](../04-DEPLOY-ARGOCD.md) — buini/teamini used in helm path construction
+
+## Sources
+
+(no raw/ sources at bootstrap)
+
+## Notes
+
+<!-- Anything below is human-owned. wiki-init never reads or modifies content under this heading. -->
+
+---
+
+[← Wiki index](../../index.md)
+
+<!-- atomic: keep this page ≤600 words. New scope → new concept page that builds on this one. Do not append paragraphs here. -->
@@ -0,0 +1,50 @@
+<!-- m-wiki: type=concept slug=whitelist-system topic=policy base-sha=28f54cf7bef9 generated-at=2026-05-12T00:00:00+00:00 sources=[] -->
+
+> Generated 2026-05-12 at base-sha 28f54cf7bef9. Type: concept. 0 sources.
+
+# Whitelist System
+
+devops-lib enforces five policy gates at runtime by cloning `Meesho/whitelists` on GitHub and reading a YAML file. This allows DevOps to grant or revoke exceptions without changing any service code or the library itself.
+
+## Where it applies in this repo
+
+`src/com/meesho/utilities/constructParam.groovy:getWhitelistedRepos`
+
+**Five whitelist files:**
+
+| File in Meesho/whitelists | Gate method | What it controls |
+|---|---|---|
+| `skip-sonar-whitelist.yaml` | `skipSonarCheckForbidden()` | Allows `skip_sonar: true` in config.yaml for Maven prd builds |
+| `app-config-disabled.yaml` | `appConfigDisabledForbidden()` | Allows `appConfigEnabled: false` in stg for Maven/Gradle |
+| `multizone-enabled-repos.yaml` | `isMultizoneEnabled()` | Marks deployables that must go via Ringmaster (not Jenkins) |
+| `allowedNonDevelopPrDeploymentToInt.yaml` | `allowedNonDevelopPrDeploymentToIntRepos()` | Allows feature-branch PRs to target `main` for int deploy |
+| `ValidateCacConfig.yaml` | `ValidateCacConfigForRepo()` | Opts repo into CAC config validation during PR builds |
+
+Each YAML file has a `repos:` list. `getWhitelistedRepos(fileName)` clones the entire `Meesho/whitelists` repo into `whitelist/` in the workspace, reads `whitelist/<fileName>.yaml`, and returns the `repos` list as a `Set`.
+
+`getWhitelistedDeployable(fileName, keyName)` is a variant that reads an arbitrary key from the YAML — used for `multizone_enabled_deployables` which is a list under a non-standard key.
+
+## Why this design
+
+Inline conditionals in stage code would require PRs to `devops-lib` for every exception. The whitelist approach lets DevOps grant exceptions by merging a one-line YAML change to `Meesho/whitelists` — visible in its own audit trail, immediately effective on the next build, and independent of the library release cycle.
+
+The cost is a fresh `git clone` per whitelist check per build. Five checks = five clones. On a slow network or under GitHub rate limiting, this adds measurable latency. This freshness guarantee is by design — never refactor `getWhitelistedRepos` to cache the clone across calls without confirming the freshness requirement is no longer needed.
+
+## Related
+
+- [Config policy](../06-CONFIG-POLICY.md) — all five gates in context
+- [CAC validation](cac-validation.md) — triggered by the ValidateCacConfig whitelist
+
+## Sources
+
+(no raw/ sources at bootstrap)
+
+## Notes
+
+<!-- Anything below is human-owned. wiki-init never reads or modifies content under this heading. -->
+
+---
+
+[← Wiki index](../../index.md)
+
+<!-- atomic: keep this page ≤600 words. New scope → new concept page that builds on this one. Do not append paragraphs here. -->