61 lines
3.3 KiB
Markdown
61 lines
3.3 KiB
Markdown
# 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
|