x/build: make a bot review CLs for common mistakes (like Tricorder)

[bradfitz]

Tracking bug to write a bot to review CLs for common mistakes:

• properly-formatted references to CLs and bugs
• conventional subject ("pkg/name: lowercase verb, not period at end")
• gofmt
• missing copyright headers

And whatever else we add in the future.

(forked from email thread https://groups.google.com/forum/#!topic/golang-dev/KpHMoePhg6c)

/cc @kevinburke @rsc

[dsnet]

What about lint and vet?

[bradfitz]

What about lint and vet?

Sure. I imagine we'd start with some basic things and once we have it automated, we can add more to it later. I wouldn't make lint & vet a requirement for the initial deployment.

[kevinburke]

IIRC @josharian has been working on getting golang/go to pass vet, but it doesn't currently, and relies on an "exemption" file for places/test files that don't pass vet on purpose.

[mvdan]

gofmt

Perhaps with -s?

properly-formatted references to CLs and bugs

Github has various accepted formats for these (https://help.github.com/articles/closing-issues-via-commit-messages/). I assume you want to limit it to "Fixes #n", though?

[bradfitz]

@mvdan, the two common mistakes I'm thinking of:

1. people write "Fixes #nnn" when they're hacking in a subrepo, and thus Github requires the fully-qualifed "Fixes golang/go#nnn" format, since Go only uses one massive bug tracker, instead of per-repo bug trackers.
2. people sometimes accidentally refer to CL numbers with the # sign, spamming ancient bugs. They should write "CL nnnn" or golang.org/cl/nnnn instead of "CL #nnn" or "change #nnn".

[ianlancetaylor]

Another common mistake is using a git SHA when they should use a CL number.

[mvdan]

Another thing that comes to mind is gerrit/github links that should be golang.org/issue/X or golang.org/cl/Y.

[minux]

I'd also like the bot to catch accidentally committing a binary, which happened at least five times (the following list is not comprehensive as I just looked at the top 12 largest files): https://golang.org/cl/4287056 1179384 bytes https://golang.org/cl/4406044 3500057 bytes https://golang.org/cl/9560 6084208 bytes https://golang.org/cl/19968 2243120 bytes I also remember one time we rewrote the git history to remove one accidentally committed binary file. I once suggested that we change Gerrit setting to reject binary files bigger than a certain size, but that was rejected. If we make such a pre-check bot, we can at least make it point out a binary file is included (and its size). This will be a warning. Another idea about spamming old bugs, also checks for tiny issue numbers (say, less than 100), because people sometimes use #1 as bulletpoints and some test output use #X as a short "Number X", I remember runtime/pprof tests do this.

[minux]

On Fri, Jan 6, 2017 at 4:31 PM, Ian Lance Taylor ***@***.***> wrote: Another common mistake is using a git SHA when they should use a CL number.

I'd like the bot to be more helpful and actually figure out the correct CL number for the git commit hash and suggest its use.

[bradfitz]

I also remember one time we rewrote the git history to
remove one accidentally committed binary file.

I have no memory of this and am pretty sure we have never rewritten the Git history.

[ianlancetaylor]

We rewrote people's memory along with the git history, to simplify matters going forward.

[minux]

On Fri, Jan 6, 2017 at 4:57 PM, Brad Fitzpatrick ***@***.***> wrote: I also remember one time we rewrote the git history to remove one accidentally committed binary file. I have no memory of this and am pretty sure we have never rewritten the Git history.

Sorry, my memory is indeed off. It's not to remove a binary file, but to revert a bad merge. https://groups.google.com/d/msg/golang-dev/2wkzNtLKWyI/bl3wVhNAIm4J It is to remove these two commits: https://golang.org/cl/5351/, commit https://go.googlesource.com/go/+/c21f1d5ef30ff52cb42fca146a9c7161dfee5c3c https://golang.org/cl/5353/, commit https://go.googlesource.com/go/+/e5048a5eaabdb86156d8de1a97d32eb898560e50

[LionNatsu]

Maybe we can add some pre-check in git-codereview? After change and before mail

[kevinburke]

@LionNatsu from the email thread:

We could have a bot that leaves comments on Gerrit for common mistakes. I'd prefer that over CLI tooling. (Not everybody uses git-codereview, especially if we start accepting Github PRs)