Files
devops-lib-gcp/docs/adr/0004-fresh-whitelist-clone-per-build.md
T
2026-08-26 02:02:24 +05:30

2.7 KiB

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.

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.