-
Type:
Task
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Build
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
- Problem
For patch builds, `version_expansions_generate.sh` appends the Evergreen `${version_id}` to `MONGO_VERSION`. The version id is unique per patch, so `--define=MONGO_VERSION=...` differs between any two patch builds — even back-to-back builds of byte-identical sources.
That define feeds the version-stamping generators (`//src/mongo/util:version_constants_gen` → `version_impl.cpp`, `releases.h`, msi/rc constants), so every patch build re-executes them, recompiles `version_impl.cpp`, and relinks *every final binary* — dragging in LTO indexing and `CcLtoBackendCompile` actions on static variants. Observed on `amazon-linux2023-arm64-static-compile` `archive_dist_test`: two identical patch builds 10 minutes apart each remotely executed the same ~250-action tail instead of hitting the cache (EngFlow invocations [d4a947df](https://sodalite.cluster.engflow.com/invocations/default/d4a947df-9446-45a8-a5c9-1eec935ba159) / [61d386c8](https://sodalite.cluster.engflow.com/invocations/default/61d386c8-6e76-4447-a036-d4721f0c7716); the only action-relevant flag diff between them was `-define=MONGO_VERSION=9.0.0-alpha0-patch<version_id>`).
-
- Fix
Replace the version id with a hash of the patched source tree: `git write-tree` over a throwaway copy of the index after `git add -A`. This covers HEAD *plus* the uncommitted working-tree changes Evergreen applies for CLI patch diffs, and respects `.gitignore`, so generated files (`.bazelrc.evergreen`, `engflow.cert`, ...) don't perturb the hash. Identical sources ⇒ identical `MONGO_VERSION` ⇒ the version-stamped tail becomes a remote cache hit.
Verified locally: the hash is deterministic across runs, changes when a tracked file is modified or an untracked file is added, is unaffected by gitignored files, and leaves the real index untouched.
-
- Trade-off
The suffix no longer identifies which Evergreen patch produced a binary — it identifies the sources instead (which is what makes caching possible). Task provenance is still available from the S3 path of the uploaded artifacts and `version_expansions.yml` (keyed by `${version_id}`).