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.

ADR-0004: Fresh Whitelist Clone Per Build — 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

3.3 KiB Raw Blame History