# 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