Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
bradfitz opened this issue Jan 6, 2017 · 62 comments
Open

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

bradfitz opened this issue Jan 6, 2017 · 62 comments
Assignees
Labels
Builders x/build issues (builders, bots, dashboards) FeatureRequest NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@bradfitz
Copy link
Contributor

bradfitz commented Jan 6, 2017

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

@bradfitz bradfitz added this to the Unreleased milestone Jan 6, 2017
@dsnet
Copy link
Member

dsnet commented Jan 6, 2017

What about lint and vet?

@bradfitz
Copy link
Contributor Author

bradfitz commented Jan 6, 2017

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
Copy link
Contributor

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
Copy link
Member

mvdan commented Jan 6, 2017

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
Copy link
Contributor Author

bradfitz commented Jan 6, 2017

@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
Copy link
Contributor

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

@mvdan
Copy link
Member

mvdan commented Jan 6, 2017

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

@minux
Copy link
Member

minux commented Jan 6, 2017 via email

@minux
Copy link
Member

minux commented Jan 6, 2017 via email

@bradfitz
Copy link
Contributor Author

bradfitz commented Jan 6, 2017

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
Copy link
Contributor

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

@minux
Copy link
Member

minux commented Jan 6, 2017 via email

@LionNatsu
Copy link
Contributor

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

@kevinburke
Copy link
Contributor

@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)

@LionNatsu
Copy link
Contributor

@kevinburke Oh, indeed.

@shawnps
Copy link
Member

shawnps commented Jan 7, 2017

I'm interested in working on this (I wrote Go Report Card https://goreportcard.com/ with @hermanschaaf which does a lot of this too).

Edit: the Go Report Card reference was just to mention that I've worked on a similar problem before and could maybe borrow some code from there.

@bradfitz
Copy link
Contributor Author

bradfitz commented Jan 7, 2017

@shawnps, the first thing to figure out is where this runs and how, and how it interacts with Gerrit.

We already have one process polling Gerrit (the build coordinator's "watcher"), and if we revamp dev.golang.org that would be a second. This would be a third. I suspect we'll want to make this bot interact with the proposed dev.golang.org all-Github-and-Gerrit-in-RAM server, and then this bot could long-poll our new "Github/Gerrit Model Server" waiting for changes (new or updated CLs).

But in the meantime I suppose it could run manually every N minutes. Please use https://godoc.org/golang.org/x/build/gerrit which we already use. If something's missing, modify that package as needed.

You'll want to store state somewhere. It's easy to find CLs the bot's already left comments on, but the bot should probably be silent and not +1 the bug if there's nothing to say, which means you'll need to store state about which bugs you've seen and are happy about. That should probably go into Google Cloud Datastore (https://cloud.google.com/datastore/) which we already use in the Go build system (see "git grep datastore" in src/golang.org/x/build/cmd/coordinator), as opposed to files on the local filesystem. (Filesystems come and go as we destroy and recreate the world)

@shawnps
Copy link
Member

shawnps commented Jan 7, 2017

@bradfitz thanks, I was just about to ask about many of the details you just listed. Taking a look at https://godoc.org/golang.org/x/build/gerrit now.

That should probably go into Google Cloud Datastore (https://cloud.google.com/datastore/) which we already use in the Go build system (see "git grep datastore" in src/golang.org/x/build/cmd/coordinator)

Found datastore reference here:

https://github.com/golang/build/blob/master/cmd/coordinator/gce.go#L119

So this particular app (coordinator) "runs on CoreOS on Google Compute Engine and manages builds using Docker containers and/or VMs as needed" - is the suggestion that the new bot would run on GCE or GAE in a similar manner to this one?

@bradfitz
Copy link
Contributor Author

bradfitz commented Jan 7, 2017

Yes, this would run on GCE somewhere.

I would start by making it a non-package main package that you can instantiate and run. Then make a tiny tiny package main runner program for it for development and local testing.

Once it's working, we can integrate that bot into something.

I also imagine that some helper environment will need to be described by a Dockerfile, since you'll want things like golint and go vet available.

@shawnps
Copy link
Member

shawnps commented Jan 7, 2017

Okay thanks. As a first step I'm currently trying to figure out how to grab files for a specific change on Gerrit in order to run gofmt on them.

@bradfitz
Copy link
Contributor Author

bradfitz commented Jan 7, 2017

Okay thanks. As a first step I'm currently trying to figure out how to grab files for a specific change on Gerrit in order to run gofmt on them.

Click "Download" in the web UI for a hint:

git fetch https://go.googlesource.com/crypto refs/changes/79/34779/8 && git cherry-pick FETCH_HEAD

You can have the bot do a shallow git clone of the parent git commit, and then chrery-pick atop that.

Alternatively, there's an API to get files from Gerrit at a specific revision as a tarball. See the cmd/coordinator code:

func getSourceTgzFromGerrit(repo, rev string) (tgz []byte, err error) {
        return getSourceTgzFromURL("gerrit", repo, rev, "https://go.googlesource.com/"+repo+"/+archive/"+rev+".tar.gz")
}

@shawnps
Copy link
Member

shawnps commented Jan 7, 2017

@bradfitz thanks, I had gotten as far as getting the FetchInfo:

package main

import (
	"fmt"
	"log"

	"golang.org/x/build/gerrit"
)

func main() {
	c := gerrit.NewClient("https://go-review.googlesource.com", gerrit.NoAuth)
	cis, err := c.QueryChanges("34871", gerrit.QueryChangesOpt{
		N: 5000,
		Fields: []string{
			"CURRENT_FILES",
			"CURRENT_REVISION",
		},
	})
	if err != nil {
		log.Fatal(err)
	}
	for _, r := range cis[0].Revisions {
		for _, f := range r.Fetch {
			fmt.Println(f)
		}
	}
}

(I know the cis[0] could panic if nothing is returned, this was just a quick test to see how far I could get right now)

I guess I can use this to get this piece: refs/changes/79/34779/8 and then do the cloning bit as you mentioned.

@shawnps
Copy link
Member

shawnps commented Jan 7, 2017

@bradfitz let me know if that looks like I'm on the right track, will be offline soon but I'll pick this back up in the morning. I appreciate all the feedback and help, thanks!

@bradfitz
Copy link
Contributor Author

bradfitz commented Jan 7, 2017

Rather than do a query for "34871", you probably just want to load the detail of a single change using https://godoc.org/golang.org/x/build/gerrit#Client.GetChangeDetail

@shawnps
Copy link
Member

shawnps commented Jan 7, 2017

@bradfitz any idea if there's a reason why GetChangeDetail doesn't take an optional gerrit.QueryChangesOpt? I was planning to go the tar.gz route but that requires the revision, which doesn't seem to be accessible unless you specify "CURRENT_REVISION".

@bradfitz
Copy link
Contributor Author

bradfitz commented Jan 7, 2017

IIRC, GetChangeDetail returns everything already, so there's no need to selectively say what you want?

If not, we can modify that package as needed.

@shawnps
Copy link
Member

shawnps commented Jan 7, 2017

@bradfitz I will dig a bit more but I think I need the current revision in order to get the tarball, and current revision only appears in ChangeInfo if you request it:

https://gerrit-review.googlesource.com/Documentation/rest-api-changes.html#change-info

see "current_revision":

"Only set if the current revision is requested or if all revisions are requested."

But maybe this is my misunderstanding of how revisions work in Gerrit.

@shawnps
Copy link
Member

shawnps commented Jan 7, 2017

@bradfitz I was able to get the revision info with this patch:

diff --git a/gerrit/gerrit.go b/gerrit/gerrit.go
index fbdc7a8..b983d90 100644
--- a/gerrit/gerrit.go
+++ b/gerrit/gerrit.go
@@ -345,9 +345,19 @@ func (c *Client) QueryChanges(q string, opts ...QueryChangesOpt) ([]*ChangeInfo,
 // GetChangeDetail retrieves a change with labels, detailed labels, detailed
 // accounts, and messages.
 // For the API call, see https://gerrit-review.googlesource.com/Documentation/rest-api-changes.html#get-change-detail
-func (c *Client) GetChangeDetail(changeID string) (*ChangeInfo, error) {
+func (c *Client) GetChangeDetail(changeID string, opts ...QueryChangesOpt) (*ChangeInfo, error) {
+	var opt QueryChangesOpt
+	switch len(opts) {
+	case 0:
+	case 1:
+		opt = opts[0]
+	default:
+		return nil, errors.New("only 1 option struct supported")
+	}
 	var change ChangeInfo
-	err := c.do(&change, "GET", "/changes/"+changeID+"/detail")
+	err := c.do(&change, "GET", "/changes/"+changeID+"/detail", urlValues{
+		"o": opt.Fields,
+	})
 	if err != nil {
 		return nil, err
 	}

without this, I've found ci.Revisions to be empty

@shawnps
Copy link
Member

shawnps commented Jan 7, 2017

CL made here for the above diff: https://go-review.googlesource.com/#/c/34922/

@bradfitz bradfitz added the NeedsFix The path to resolution is known, but the work has not been done. label Feb 15, 2018
@bradfitz
Copy link
Contributor Author

We had a long-running dup bug that I just closed, but contains discussion and links: #20648

@gopherbot

This comment has been minimized.

gopherbot pushed a commit that referenced this issue May 30, 2018
CL 109361 introduced some changes which were not properly gofmt'ed.
Because the CL was sent via Github no gofmt checks were performed
on it (cf. #24946, #18548).

Change-Id: I207065f01161044c420e272f4fd112e0a59be259
Reviewed-on: https://go-review.googlesource.com/115356
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
@bradfitz bradfitz assigned dmitshur and unassigned bradfitz and andybons Aug 3, 2018
@dmitshur dmitshur removed their assignment Aug 3, 2020
@cagedmantis cagedmantis self-assigned this Jul 15, 2022
@heschi heschi added this to In Progress in Go Release Team Jul 26, 2022
@dmitshur dmitshur moved this from In Progress to Planned in Go Release Team Aug 2, 2022
@heschi heschi moved this from Planned to In Progress in Go Release Team Aug 23, 2022
@cagedmantis cagedmantis moved this from In Progress to Planned in Go Release Team Sep 6, 2022
gopherbot pushed a commit to golang/build that referenced this issue May 2, 2024
Remove it. It has too many false positives. There are no more checkers
running, but it's still worthwhile to leave so we can easily add them
back in the future.

Updates golang/go#18548.

Change-Id: Ifbaf9a7d6cf685132587702b923a73a01a4ac419
Reviewed-on: https://go-review.googlesource.com/c/build/+/582956
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Russ Cox <rsc@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
@gopherbot
Copy link
Contributor

Change https://go.dev/cl/582956 mentions this issue: tricium_simple: remove HTTPS checker

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Builders x/build issues (builders, bots, dashboards) FeatureRequest NeedsFix The path to resolution is known, but the work has not been done.
Projects
Status: Planned
Development

No branches or pull requests