Golang In multi-module Git repos, local Go compilations stamp the wrong main module version for main packages that are in a non-root Go module

Go version

go1.24.4 linux/amd64

Output of go env in your module/workspace:

AR='ar'
CC='gcc'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='g++'
GCCGO='gccgo'
GO111MODULE=''
GOAMD64='v1'
GOARCH='amd64'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/home/<username>/.cache/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/home/<username>/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build2863849951=/tmp/go-build -gno-record-gcc-switches'
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMOD='/dev/null'
GOMODCACHE='/home/<username>/code/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/<username>/code'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTELEMETRY='local'
GOTELEMETRYDIR='/home/<username>/.config/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.24.4'
GOWORK=''
PKG_CONFIG='pkg-config'

What did you do?

git clone https://github.com/go-fuego/fuego && cd fuego/cmd/fuego && go build . && go version -m ./fuego
go install && go version -m $GOPATH/bin/fuego
rm -rf $GOPATH/bin/fuego && go install github.com/go-fuego/fuego/cmd/fuego@latest && go version -m $GOPATH/bin/fuego
cd ../../.. && rm -rf fuego && rm -rf $GOPATH/bin/fuego 

What did you see happen?

Generating a binary locally (via either go build . and go install) stamps a pseudo-version for the main module based off of the Git repo's root Go module's git tag whereas generating one from the remote repo (go install github.com/go-fuego/fuego/cmd/fuego@<version>) stamps the correct main module version.

What did you expect to see?

I expect local Go compilations to stamp the correct main module's version like remote go installs do.

Other notes

• I've reproduced this outside of a Go workspace. I'm unaffiliated with the repo I used in this issue's reproduction; it was just a public repo with that matched the constraints I had: public, multi-module Go repo using git where the root module's version had a different major or minor version than the binary's module's version (so we could see which module the pseudo-version was based off of) and where package main for the binary's source was in the same folder as its go.mod file.
• I've reproduced the same behavior using a non-GitHub git host.
• I haven't tried to reproduce yet in a non-git vcs.
• After a skim of the Go codebase, I think the issue is either the value of the codeRoot argument passed into src/cmd/go/internal/modfetch/coderepo.go:newCodeRepo or happens in in the function itself (or something it calls).
• The effect of this bug is that runtime/debug.ReadBuildInfo returns the wrong main module version, a value that I wish to annotate my logs with since the vcs fields seem to be unreliable and/or affect build reproducibility.
• Possibly related comment by @DavidGamba

Comment From: gabyhelp

Related Issues

• cmd/go: unknown revision when using semver tag for module in subdirectory #31045 (closed)
• cmd/go: local version stamping doesn't work with v2+ #72877 (closed)
• cmd/go: stamped (pseudo) version on build does not work for module in subdirectory #71738 (closed)
• Go doesn't respect main module when building from outside the module #34314 (closed)
• cmd/go: complete documentation for module code layout #30850 (closed)
• cmd/go: specifying module branch writes incorrect version tag to go.mod #31287 (closed)
• cmd/go: rough UX for developing multiple modules in one repository #39993 (closed)
• cmd/go: in mod 'go get' some module's version taged not from master branch failed #36599 (closed)
• cmd/go: mod download modpath@HEAD erroneously resolves to a pseudo-version when HEAD is subsequently tagged #37336
• cmd/go: poor error message when resolving an import path that is missing from the main module #38224

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

Comment From: EmperorEarth

Thanks @seankhliao; I didn't get that issue as a result when I searched earlier!