ADR-0005: Config-Only Change Detection — Skip Binary Build, Reuse Latest Image

Status: Accepted Category: PATTERN Date decided: Mid-project Date documented: 2026-05-12

Context

Meesho services store both application code and deployment configuration (Helm values, AppConfig YAML) in the same repository. Teams frequently push config-only changes — tweaking memory limits, updating feature flags, changing environment variables — that do not require recompiling the binary or rebuilding the Docker image. Without detection, every such commit triggers a full 10–15 minute CI run: compile, test, sonar scan, Docker build, image push — then deploy the same binary that was already running.

Decision

Each build stage checks whether the Git diff contains only *.yaml file changes (no source code). If so, the binary build, Docker build, and image push are entirely skipped. The latest image tag is fetched from Google Artifact Registry (GAR) and used directly for the ArgoCD deployment. The full build runs only when source code changes are present.

Alternatives Considered

Always run the full build: Rejected — config rollouts would take 10–15 minutes when the only change is a YAML file, causing friction and delaying incident response (e.g., bumping a memory limit during an OOM incident).
Separate repos for code and config: Considered but rejected — splitting config into a separate repo adds operational complexity (two PRs for one change, out-of-sync risk) without proportional benefit.

Consequences

Positive:

Config rollouts (AppConfig changes, Helm value tweaks, memory limit bumps) complete in ~2 minutes instead of 10–15 minutes.
Reduces unnecessary Docker image churn — no new SHA for a commit that didn't change the binary.
Faster incident response: an engineer can bump memory_request during an OOM and see it deployed in minutes.

Negative:

The detection is heuristic — it checks file extensions, not semantic content. A YAML file that configures build behaviour (e.g., a hypothetical .github/workflows/ file) would be misclassified as a config-only change.
The latest image tag from GAR must exist; if the previous build failed before pushing an image, a config-only change will fail to find a tag to deploy.

Neutral:

The config-only path still triggers the ArgoCD deployment steps — only the build and image push are skipped.

Constraints

Build time was the primary constraint. Teams were complaining about slow feedback cycles for config changes. The detection logic was the minimal implementation that addressed this without a repo restructure.

Current Assessment

Still appropriate — no changes needed.

Notes

Key file: src/com/meesho/stages/buildGo.groovy:is_config_only_change_and_should_deploy_argo() (reference implementation; similar logic exists in other build stages)
The TODO comment in buildMaven.groovy:70 notes that appConfig changes also currently trigger a build — this is a known gap

3.0 KiB Raw Blame History Unescape Escape