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,60 @@
+# ADR-0003: Policy Exceptions Controlled by a Separate Meesho/whitelists Repo
+
+**Status:** Accepted
+**Category:** PATTERN
+**Date decided:** Early on
+**Date documented:** 2026-05-12
+
+## Context
+
+The shared CI/CD library enforces several policies by default: SonarQube quality gate, AppConfig validation, CAC config validation, multizone deployment restrictions. Some services legitimately need to bypass these policies (e.g., a legacy service that cannot pass sonar without significant rework, or a service that doesn't use AppConfig). The question is where to store these exceptions and who can grant them.
+
+## Decision
+
+Policy exceptions are controlled by YAML files in a separate `Meesho/whitelists` repository, not by flags in each service's `config.yaml`. There are five active whitelist files:
+
+| Whitelist | Controls |
+|---|---|
+| `skip-sonar-whitelist` | Repos that skip SonarQube scanning |
+| `app-config-disabled` | Repos that skip AppConfig validation |
+| `multizone-enabled-repos` | Repos that must deploy via Ringmaster (not Jenkins) |
+| `allowedNonDevelopPrDeploymentToInt` | Repos allowed to deploy non-develop PRs to int |
+| `ValidateCacConfig` | Repos that run CAC config validation |
+
+Adding or removing a repo from any whitelist requires a PR to `Meesho/whitelists` reviewed and merged by the DevOps Platform team.
+
+## Alternatives Considered
+
+- **Flags in each service's config.yaml** (e.g., `skip_sonar: true`): Rejected because service teams could self-grant bypass without DevOps review, making it impossible to audit or enforce policy. Note: `config.yaml` does contain a `skip_sonar` field, but `constructParam.groovy` explicitly throws an exception if a repo sets it to `true` without being on the skip-sonar-whitelist — the whitelist is the authoritative gate.
+- **Hardcoded exceptions in devops-lib source**: Rejected because adding an exception would require a devops-lib PR, which is heavier than a whitelists PR and conflates policy with pipeline logic.
+
+## Consequences
+
+**Positive:**
+- DevOps Platform team retains ownership of all policy exception grants — service teams cannot bypass sonar or multizone enforcement unilaterally.
+- All exceptions are visible in one repo — easy to audit who has what bypass and why.
+- Policy can be tightened or relaxed without touching devops-lib or any service repo.
+
+**Negative:**
+- Adding a legitimate exception requires a separate PR to a different repo, adding friction for service teams.
+- The whitelist repo is a single point of dependency — if it's unreachable, every build that checks whitelists fails.
+
+**Neutral:**
+- The whitelist is re-cloned fresh on every build (see ADR-0004), so changes take effect immediately without a devops-lib release.
+
+## Constraints
+
+Audit requirements and DevOps policy ownership drove the decision to separate exception management from service config.
+
+## Current Assessment
+
+**Still appropriate** — no changes needed.
+
+## Related Decisions
+
+- [ADR-0004: Fresh Whitelist Clone Per Build](0004-fresh-whitelist-clone-per-build.md) — How whitelist changes take effect immediately.
+
+## Notes
+
+- Key file: `src/com/meesho/utilities/constructParam.groovy:getWhitelistedRepos()` — all whitelist lookups go through this method
+- `config.yaml` has a `skip_sonar` field but it is rejected by `constructParam.groovy` unless the repo is also on the whitelist