ADR-0010: Cloud-and-branch namespaced artifact paths

Status: Accepted Category: DATA Date decided: Project inception Date documented: 2026-05-13

Context

Every service build in devops-lib produces a deployable artifact (Maven JAR / language-equivalent) plus a Docker image; the pipeline must decide where to store these and whether a re-run on the same commit can short-circuit a rebuild. The library was written when both AWS and GCP backends were on the table, so the storage layer was parameterised by provider scheme; in practice the platform has since standardised on GCP and the s3:// code paths are vestigial. PRs and release branches share the same Jenkins jobs but have very different trust levels — a PR artifact must never be promotable to a production tag.

Decision

Artifacts are stored under fully-namespaced paths of the form <scheme>://<bucket>/<repo_name>/<branch_name>/<TAG>/, where <scheme> is gs:// in active use (s3:// branches remain in the codebase but are not executed today). Release branches (main / master / gcp-main) and develop reuse cached artifacts on re-run via checkS3(); PR builds intentionally bypass that check and force a fresh build every time.

Alternatives Considered

No alternatives were explicitly evaluated by the team during this interview. The branch-namespaced layout was the day-one design and has not been revisited.

Consequences

Positive:

A PR's image cannot be confused with a release image at the bucket-path level — provides a structural guarantee against accidental promotion.
Re-running a build on the same release branch is free (artifact reuse), keeping incremental commits cheap.
Multi-cloud scheme prefix is harmless even when only one cloud is active; switching back would be a config change, not a rewrite.

Negative:

s3:// code paths sit unused in buildMaven.groovy and friends — invisible tech debt that confuses new readers and grows the surface area for stale-config bugs.
The (branch_name, TAG) key means renaming a branch or rebasing a PR can leak artifacts into the wrong namespace if branch_name is computed loosely.

Neutral:

Cache reuse is implicit (artifact-exists ⇒ skip build) rather than declared — see ADR-0005 for the config-only fast-path that uses the same mechanism.

Constraints

Branch identity is the cache key, so branch_name must be a stable string for the lifetime of a build chain. PR-target detection (env.CHANGE_ID) is load-bearing here.
AWS code paths exist for historical reasons; today's platform is GCP-only and the team has not undertaken a cleanup pass.

Current Assessment

Adequate with caveats — the strategy is sound; the vestigial AWS branches are noise that should be removed in a separate cleanup.

ADR-0005: Config-Only Change Detection — Skip Binary Build, Reuse Latest Image — the same artifact-existence check powers the config-only fast-path.

Notes

Key files: src/com/meesho/stages/buildMaven.groovy
The s3:// branches in buildMaven.groovy are dead code in current production — flag for cleanup, not for documentation as an alternative.
Discovery id: DATA-1

3.4 KiB Raw Blame History