-
Type:
Improvement
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
DevProd Build
-
None
-
None
-
None
-
None
-
None
-
None
-
None
Deploying custom builds comes with a massive footgun: if the gitVersion matches an existing build with the same gitVersion, the build will not be considered different and will not be picked up by the Agent. This makes custom builds hard to deploy without git trickery, and slows down deployment times for custom builds.
There is not a reliable, canonical way to determine whether two mongod builds are identical. The current approach used by the Automation Agent compares the parsed "version" and "gitVersion" from the --version/buildInfo. Unfortunately, Evergreen generate the gitVersion using the commit hash of the base commit of a given patch build. As a result, different builds, despite differing in their contents, will have identical gitVersions and parsed version strings.
The linker already generates a build ID in the ELF file, which we can use to help determine whether two builds are identical. For example:
readelf -n bazel-out/aarch64-opt/bin/install/bin/mongod
Displaying notes found in: .note.gnu.build-id
Owner Data size Description
GNU 0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring)
Build ID: 107b4325e446b2dd591c8de6c91fe9a5afad5359
Bit-for-bit identical binaries are guaranteed to have the same build ids. The docs for (ld) say:
The "md5", "sha1", and "xx" styles produces an identifier that
is always the same in an identical output file, but are almost
certainly unique among all nonidentical output files. It is
not intended to be compared as a checksum for the file's
contents. A linked file may be changed later by other tools,
but the build ID bit string identifying the original linked
file does not change.
This request is for the mongod --version and buildInfo output to include a "buildId" which can be used by the Automation Agent to supplement existing checks to determine whether two binaries are different.
It's also worth noting that in the API we provide, the "buildId" may not always be present, either on old versions or because it may not be present on Windows where we use a different compiler.