A shipped Go binary's version output shows no commit hash. How do you establish what it was built from?

## Ask the artifact The release engineer's question months later is narrow: *what source produced this exact file?* The build logs may be expired, the tag may have moved, the pipeline may have been rewritten twice. The binary, however, still carries whatever the `go` command wrote into it, and it carries it wherever the file was copied. ``` go version -m ./release/tool ``` That prints the same record `debug.ReadBuildInfo` would return inside the process: the toolchain version, the main package path, the main module, each linked dependency module with its selected version and checksum, and every build setting. Do it against the artifact you actually shipped — the one in the release store — not against a fresh rebuild, because a rebuild answers a different question. ## Reading the three outcomes **A record with no `vcs.*` keys.** This is the common case and it is not a stripping problem. The `go` command stamps version-control data only when the main package and its module sit in a supported working tree and the tool is usable, and `-buildvcs` defaults to `auto`, which omits the data silently rather than failing. So the build ran from an unpacked source archive, or in an environment with no repository metadata or no version-control tool, or someone added `-buildvcs=false` months ago to get past a build error. Look at the other settings in the same dump: `-trimpath`, `-tags`, `GOOS`, `GOARCH`, `CGO_ENABLED` and the `-ldflags` value often identify which build path produced the file even when the revision is missing. **`vcs.revision` present with `vcs.modified=true`.** Now the hash is a lead, not an answer. It says the tree was based on that commit and then edited. Checking out that commit gives you something close to, but demonstrably not, the source that was compiled. For a production incident this is the worst of the three outcomes because it looks trustworthy at a glance. **No record at all** — `ReadBuildInfo` reporting false and `go version -m` printing nothing for the file. That means the executable was not produced by the `go` command in module mode, or the record was destroyed by a post-processing step. Note what does *not* cause this: linking with `-ldflags "-s -w"` removes the symbol table and DWARF debugging data and leaves the build record readable, so blaming stripping is usually wrong. ## Cross-checking the running process If the deployed process reports a different revision from the artifact you are inspecting, then it is not that artifact. The comparison is worth making explicitly: have the process print its own record and diff it against `go version -m` on the file in the release store. A mismatch reframes the incident from "which commit is broken" to "why did we deploy something we did not publish", which is a different investigation entirely. ## Also check the dependencies The record lists the modules that were actually linked in, with resolved versions. When two artifacts built from the same commit behave differently, that list is where the difference shows up — a `replace` target that only exists in one build environment, or a version that resolved differently. ## Closing the hole Diagnosis is one thing; not repeating it is the point. Three changes usually suffice. Make the `version` subcommand print the whole record, marking a dirty build visibly rather than showing a clean-looking hash. Have the release job run `go version -m` on the artifact it is about to publish and store that output alongside it, so the record survives even if the artifact is later lost. And make the job refuse to publish when `vcs.revision` is empty or `vcs.modified` is `true`, which converts a future archaeology dig into a build failure someone fixes in ten minutes.