CL 393894

I agree that the VCS information should not be included by default. But if you specifically add -buildvcs=true, it should either include the information or error out. In my case, I'm testing a package that parses debug.ReadBuildInfo, which is kind of a weird thing to do, but I don't think it's so weird that the VCS information should never be includable.

I suppose that now that we have -buildvcs=auto, we could theoretically make -buildvcs=true add stamping for tests. 🤔

I'd like to see consistency in behavior across the different go tools. If go test -buildvcs=true adds stamping for tests, then go run -buildvcs=true should add stamping too.

I wouldn't want to see us end up in a scenario like this:

• go build adds stamping by default (if a VCS repo is present)
• go test only adds stamping if -buildvcs=true
• go run never adds stamping, even if -buildvcs=true (which is where things were left on cmd/go: Since 1.18.1, go run always uses -buildvcs=false #52338)

I think it’s fine for go test to default to omitting and go run to disallow it, but it should error out if you request an impossible option.

Change https://go.dev/cl/409177 mentions this issue: cmd/go: stamp VCS information in test binaries when -buildvcs=true

@gopherbot, please backport to Go 1.18. The requested -buildvcs behavior for this particular use-case was present in Go 1.18, but regressed in Go 1.18.1 as a byproduct of the fix for #51767. Now that -buildvcs=auto has been added for #51798, the Go 1.18 behavior for -buildvcs=true can be restored.

Backport issue(s) opened: #53177 (for 1.18).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases.

If this invalidates the test cache after every git commit, this sounds like a really bad idea to me.

What real world use case would be enabled by this behaviour?

Testing that your binary contains build information.

Most people should have it set to auto or off most of the time. What’s the problem with slow builds for people who deliberately turn it on?

With respect to backports, what's the status of this bug/fix?
#53177 (1.18 backport) is still open.

The backport is waiting on a bit of soak time. (The need for soak time is why it didn't make 1.19 as well.)