add a "bug" command to pre-fill a bug template

[mvdan]

This idea is copied from other projects.

We could set up a bug report template, requesting lots of information about the user's system, but that has two issues:

1. Some people will just ignore the template, or fill it incorrectly.
2. Filling the template properly takes a lot of copy pasting, especially as we will want many things: go version, go env, etc.

If we make garble bug the main and recommended way to file bugs, both of those problems sort of go away. If someone files a bug without using garble bug, we can tell them to use it instead.

A garble bug could potentially do extra stuff in the future. For example, give high-level details of the previous garble build command, if it failed, without leaking crucial information about the code being built. Such information could include:

• What command was run, and with what explicit Go env vars like GOPRIVATE?
• At what stage did garble fail? Obfuscating a package, compiling a package, linking a binary...?
• What was the error output?

With issues like #218, the "what was the error output?" bit would be extra useful, since it would contain more context.

[mvdan]

By default, garble bug would open a browser on the "new issue" page with pre-filled content. It would not be posted unless the user clicks the "post" button.

For the use case where someone wants to be in control, or more easily copy-paste the output, we could also have garble bug -n to just print the filled template to stdout.

[pagran]

A small note, the environment variables can expose the user's "private" information (e.g. the name of his user account in the system)
And I think in some cases it is useful attach sources + seed

[mvdan]

A small note, the environment variables can expose the user's "private" information (e.g. the name of his user account in the system)

That is why I said "explicit Go env vars". I don't think anything in go env could ever leak personal information or secrets. And in the rare case it could, the user can always review before posting.

And I think in some cases it is useful attach sources + seed

The seed should be included via either the command that was run, or the error (#212).

We can't attach entire sources, or even partial ones, because I imagine that wouldn't be OK to automate for the vast majority of users.

However, when they report a compile error mentioning the real foo/bar.Baz function or type, we can ask them what it looks like and if it's special in any way. It should also make it far easier for the user to extract that code into a small reproducer, because they know what piece of code makes the build fail.

[mvdan]

#390 adds a template; this issue remains open for now, until we implement garble bug - or choose not to implement it at all.