fix: report the installed version for go install builds - #6
Merged
Conversation
`commitlint version` reported 0.0.0-dev for every binary the release
workflow did not build — including `go install ...@vX.Y.Z`, which is the
install path the README documents and the one the GitHub Action uses. Only
release archives carried a real version, so the common case was the broken
one.
The Go toolchain already records the module version in the binary:
$ go version -m commitlint
mod github.com/DivergentCodes/commitlint v1.1.1 h1:uqR3...
Read it back with debug.ReadBuildInfo when the ldflags stamp is absent.
Precedence is stamp, then build info, then the default, so release archives
are unaffected. "(devel)", which a local build records, is suppressed in
favor of the more informative default.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VSrrciEDBTuFNMtKocScML
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Found while verifying that the GitHub Action can install the linter from the private repo: the install worked, but the binary reported the wrong version.
versionis only ever set by the release workflow's-ldflags. Every other build leaves it at the default — includinggo install ...@vX.Y.Z, the install path the README documents and the one the GitHub Action uses. So release archives reported correctly and the common case didn't.Fix
The toolchain already records the module version in the binary:
That's exactly what
debug.ReadBuildInfo()returns asinfo.Main.Version, so read it back when the ldflags stamp is absent. Precedence: stamp → build info → default.(devel), which a localgo buildrecords, is suppressed in favor of0.0.0-dev— it's less informative, not more.Verification
-X main.version=v9.9.9→ reportsv9.9.9(release archives unaffected)0.0.0-dev, not(devel)go installpath: confirmed viago version -mthat Go embedsmod ... v1.1.1in the installed binary — the exact field the fallback readsgo vet,go test -race ./...cleanNote the added test pins precedence and the no-
(devel)/no-empty guarantee, but cannot assert the installed-version path directly: undergo testthe module version is always(devel). Thego version -moutput above is the real evidence for that path, and the test comment says so rather than implying more coverage than exists.Zero third-party dependencies preserved (
runtime/debugis stdlib).🤖 Generated with Claude Code
https://claude.ai/code/session_01VSrrciEDBTuFNMtKocScML