51 lines
2.7 KiB
Markdown
51 lines
2.7 KiB
Markdown
# 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.
|