proposal: cmd/go: add `go env -bug-report`

[Jorropo]

Proposal Details

The bug issue template asks the users for go env, this is a bit big and hard to parse through.

In #77482 @dmitshur uses go env -changed which is much easier to read but it's not always enough information.

It might be nice if we had an in between that always show important environment dependent variables and go env -changed.
So in other words:
go env -bug-report would always show:

• GOVERSION
• GOARCH
• GOOS
• ... ?

And it would also show anything else go env -changed would show.

[seankhliao]

Personally I consider ~all the things in go env relevant to a bug report, as it tells us things the reporter may have otherwise omitted.
I think -changed is less about being easier to read, and more about identifying non-default settings.

[gabyhelp]

Related Issues

• cmd/go: make bugreport tool or extend env to include more info #16635 (closed)
• cmd/go: `go bug` should use `go env -changed` #67769 (closed)
• cmd/go: add a way to query for non-defaults in the env #34208 (closed)
• cmd/go: show the version GOROOT corresponds to in `go bug` output #15877 (closed)
• cmd/bug: Exclude GOPRIVATE from go bug by default #73099 (closed)
• cmd/go/internal/bug: the implementation should have more comments #45803 (closed)
• proposal: Go Env : Add go.environment #57539 (closed)
• cmd/go: env should report GOPACKAGESDRIVER #75930
• github: issue template should prompt if toolchain is go1.23 and above use go env -changed report bug #67767 (closed)

Related Code Changes

• cmd/go: update go bug to be more consistent with Github issue template

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

[dmitshur]

I agree that go env -changed cannot fully replace go env, but it can be a useful addition in many cases. Go's CI system prints all 3 of go env, go env -changed, and even cmd/internal/metadata for this reason: see crrev.com/c/6581325.

Also see issue #75043. Comments in that issue suggest that additional information printed by GOTOOLCHAIN=local go version and GODEBUG=toolchaintrace=1 go version would be useful to include in bug reports, and that the fact those commands involve temporarily setting environment variables makes them less portable across OSes.

Next, how would this flag intersect with the go bug command that already exists?

I think this needs some thought, but if it turns out possible to unify all that information into a single command invocation (potentially with flags, but not something requiring temporary environment variable changes), I think that increases chances of something like this being worthwhile.

[Jorropo]

I didn't knew go bug existed. Whatever go env -bug-report generates would be included in the go bug filled in.

About #75043 maybe this proposal should be go bug -text or something and have the rest of the required info,
there will always be people (like me) who aren't aware of go bug or run go on a remote server and we need the github template to tell them what to do to fill in the bug report.

---

@seankhliao I think most of the go env values are extremely predictable, if you need it to debug something and it is missing you can assume it is the default value, otherwise go env -changed behavior would show it.
The ones that are not predictable (GOVERSION, GOARCH, GOOS, ¿ ... ?) should be always shown.

[mvdan]

Why not just do this as part of go bug? Do we need another flag?

[Jorropo]

We need a command that outputs text so you can fill in the issue template.
Consider your go instance might be on a remote server where go bug can't open the web browser,
or like me you didn't knew go bug exists, you would then open a new issue in github and follow the template there.

This could be go bug -text or smth.