Two Go builds of the same commit produce binaries with different SHA-256 hashes. How do you make them identical?

## Frame the problem "Same commit, different bytes" means some input to the build was not the same. The source was; something else was not. The work is enumerating the inputs and finding the one that varied, and Go makes that unusually tractable because the artefact records much of its own provenance. ## Step 1: read what the binaries say about themselves ``` $ shasum -a 256 app-ci app-laptop $ go version -m app-ci > ci.txt $ go version -m app-laptop > laptop.txt $ diff ci.txt laptop.txt ``` `go version -m` prints the Go version that built the binary, the module it came from, the dependency modules and their versions, and the build settings in effect — things like `-trimpath=true`, `CGO_ENABLED`, `GOARCH` and `GOOS`. In most real cases the diff of those two outputs is the whole answer: one side is a different toolchain patch release, or one side had cgo enabled, or one side was trimmed and the other was not. ## Step 2: the inputs that must match - **Toolchain version.** Different Go releases generate different code; even a patch release can. This is recorded in the binary, and it is the single most common difference between a developer laptop and a CI image. Pin it deliberately rather than letting each machine use whatever it has installed. - **Target settings.** `GOOS`, `GOARCH` and their companions. Cross-compiling to the same target from two different hosts is fine; compiling to two different targets is not the same build. - **`CGO_ENABLED` and the C toolchain.** With cgo on, a whole second compiler participates, with its own version, its own flags and its own habit of recording paths. `CGO_ENABLED=0` removes that entire class of variation, which is why reproducible-build recipes reach for it when the program allows. - **Resolved dependency versions.** The same commit should resolve identically, but only if the build actually uses the recorded requirements rather than being allowed to update them. The dependency list printed by `go version -m` makes any drift visible. - **Build tags and compiler or linker flags**, including anything supplied invisibly through `GOFLAGS`. Check `go env GOFLAGS` on both machines; a persisted `go env -w` setting on one of them is a classic silent difference. - **The build directory.** Absolute source paths are recorded in the output by default, so two checkouts in different directories differ. `-trimpath` replaces those paths with module- and import-path-based names and removes the variable entirely. Turn it on before you go looking for anything more exotic. ## Step 3: rule out the build cache, explicitly Engineers reach for "maybe the cache served something stale" early, and it is worth killing that hypothesis at once rather than leaving it as background noise. Cache entries are keyed by a hash of every input to the action; a stored result is reused only when the key matched, and if the key matched, recompiling would produce the same bytes. So the cache cannot be the source of a difference. The demonstration takes two commands — rebuild with `-a`, which reuses nothing, and hash the result; it matches the cached build. If you want the reverse experiment, `go clean -cache` and rebuild: still the same bytes. The cache is a speed mechanism with no influence on output. ## Step 4: look at what the build reads that you did not think of When the settings match and bytes still differ, the remaining suspects are inputs the source tree brings along: - **committed generated code that is not deterministic** — a generator whose output depends on map iteration order or on the time it ran will differ between regenerations, and the difference reaches the binary, - **embedded files that are not identical** on the two machines, including anything a build script writes before compiling, - **line endings or file mode differences** from a checkout configured differently on one side. At that point `go build -x` on both machines, with the outputs diffed, shows the exact command sequence each build executed, which narrows the failure to a single step rather than a whole pipeline. ## Step 5: make it stick Having achieved identical bytes once, encode it: pin the toolchain, fix `CGO_ENABLED` and the target explicitly in the release script, pass `-trimpath` there rather than trusting the environment, and have the pipeline hash the artefact and compare it against a second, independent build of the same commit. That comparison is a cheap continuous check — it fails the day someone changes a build input without meaning to, which is exactly the day you want to hear about it rather than during an incident six weeks later. The payoff is not aesthetic. Byte-identical builds mean an artefact can be re-derived from a commit and verified rather than trusted, that a cache or mirror serving you a binary is checkable, and that "the binary in production does not match what we think we shipped" becomes a question with an answer.