# ADR-0004: Whitelist Cloned Fresh on Every Build — No Caching

**Status:** Accepted
**Category:** PATTERN
**Date decided:** Early on
**Date documented:** 2026-05-12

## Context

`constructParam.groovy` checks several whitelists (sonar skip, multizone, AppConfig, CAC, non-develop PR deploy) on every build. Jenkins agents are long-lived processes that handle many builds sequentially. If the whitelist were cached in agent memory or on disk, a policy change (adding or removing a repo from a whitelist) would not take effect until the agent restarted or the cache expired.

## Decision

`getWhitelistedRepos()` clones `Meesho/whitelists` fresh from GitHub on every build invocation. No in-memory cache, no disk cache, no TTL — each build gets the current live state of the whitelist at that moment.

## Alternatives Considered

- **Cache with TTL (e.g., 5 minutes)**: Rejected because a DevOps engineer who merges a critical policy change (adding a repo to skip-sonar during an incident) would have to wait for the cache to expire — unacceptable for incident response.
- **Cache per Jenkins agent restart**: Rejected for the same reason — agents can run for hours/days, making cache invalidation unpredictable.
- **Webhook-triggered cache invalidation**: Not evaluated — the simplicity of a fresh clone was preferred over building an invalidation mechanism.

## Consequences

**Positive:**
- Policy changes take effect on the very next build after the whitelist PR is merged — no devops-lib release required.
- No cache invalidation complexity; the whitelist state is always authoritative.

**Negative:**
- Each build that checks a whitelist incurs a `git clone` of `Meesho/whitelists`. At high build throughput, this is measurable latency.
- If `Meesho/whitelists` is temporarily unreachable (GitHub outage, network partition), all builds that check whitelists fail.

**Neutral:**
- Multiple whitelist checks in a single build (sonar + AppConfig + multizone) each clone the repo separately — there is no deduplication within a single build.

## Constraints

Incident response requirements made immediate policy enforcement non-negotiable. The extra clone latency was accepted as the cost of correctness.

## Current Assessment

**Still appropriate** — no changes needed.

## Related Decisions

- [ADR-0003: Policy Exceptions in Separate Whitelist Repo](0003-policy-exceptions-in-separate-whitelist-repo.md) — The whitelist repo this decision is about.

## Notes

- Key file: `src/com/meesho/utilities/constructParam.groovy:getWhitelistedRepos()`
- **Never refactor this to cache across calls** — the fresh-clone behaviour is load-bearing for incident response. This is documented in CLAUDE.md under NEVER DO.