| commit | fa31e3b203a806370ffef8adb673aba95cb9f49d | [log] [tgz] |
|---|---|---|
| author | thepudds <thepudds1460@gmail.com> | Tue Jul 29 15:30:07 2025 -0400 |
| committer | t hepudds <thepudds1460@gmail.com> | Wed Jul 30 10:00:45 2025 -0700 |
| tree | 517fe63c3079d6156e2d3a4361c7eb3457a9a1b8 | |
| parent | d7bc003641abec0aa11235bba378c85c96e02b1c [diff] |
cmd/gerritbot/internal/rules: make user recommendations more explicit In CL 513397, I added a small rules engine to GerritBot along with a set of rules to flag common mistakes made by external contributors, targeting PRs imported from GitHub. Part of the intent was to give immediate feedback and get people to more quickly perform their first concrete use of Gerrit, such as logging in for the first time or tweaking the commit message. This might then help them be more ready when a human reviewer shows up later. Around 75% of GitHub PRs get flagged in practice, and the rate is even higher for first-time contributors. It also seems to help experienced contributors who are still using PRs when they might accidentally use markdown or otherwise not quite follow the Go project conventions. (Experienced contributors seem more likely to fully fix everything flagged; newer contributors might only address a subset of problems flagged, but that still accomplishes the goal of getting them to successfully interact with Gerrit before a human reviewer engages. Some people seem not to take any action until they are sometimes asked multiple times by human reviewer, or the end result might be the human reviewer decides something more minor is not worth a round of feedback.) This CL adjusts some of the wording and user advice based on having now observed how people react. One of my concerns prior to initially going live was that some percentage of people might be annoyed by a nitpicking bot, especially if it was wrong. In practice, the false positive rate has been extremely low, and I don't think I've seen anyone express material annoyance. This CL therefore reduces some of the "pre-apology" text and moves it later. This also helps people see the listed problems more easily. This CL also tries to make some of the instructions more explicit especially in areas where the behavior of the end-to-end PR importing system might be somewhat counter-intuitive to some people. This includes bigger anchor text in the commit editing advice to better catch the eye of people who only skim but might spot a useful link while scanning. This CL does not change any of the detection logic in the rules -- it just changes the wording (plus a small amount of plumbing to enable that). 'go test -cover' currently reports 99.5% of statements covered in the internal/rules package. I have some other related WIP changes, but I am attempting to keep this CL somewhat narrowly scoped. Updates golang/go#61573 Change-Id: I4d3ac3c31779855e99d6e33125b8a81d505fd6f6 Reviewed-on: https://go-review.googlesource.com/c/build/+/691517 Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: Mark Freeman <mark@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
This repository holds the source for various packages and tools that support Go's build system and the development of the Go programming language.
Warning: Packages here are internal to Go's build system and its needs. Some may one day be promoted to another golang.org/x repository, or they may be modified arbitrarily or even disappear altogether. In short, code in this repository is not subject to the Go 1 compatibility promise nor the Release Policy.
This repository uses Gerrit for code changes. To contribute, see https://go.dev/doc/contribute.
The git repository is https://go.googlesource.com/build.
The main issue tracker for the build repository is located at https://go.dev/issues. Prefix your issue with “x/build/DIR: ” in the subject line.
The main components of the Go build system are:
The coordinator, in cmd/coordinator/, serves https://farmer.golang.org/ and https://build.golang.org/. It runs on GKE and coordinates the whole build system. It finds work to do (both pre-submit “TryBot” work, and post-submit work) and executes builds, allocating machines to run the builds. It is the owner of all machines. It holds the state for which builds passed or failed, and the build logs.
The Go package in buildenv/ contains constants for where the dashboard and coordinator run, for prod, staging, and local development.
The buildlet, in cmd/buildlet/, is the HTTP server that runs on each worker machine to execute builds on the coordinator's behalf. This runs on every possible GOOS/GOARCH value. The buildlet binaries are stored on Google Cloud Storage and fetched per-build, so we can update the buildlet binary independently of the underlying machine images. The buildlet is the most insecure server possible: it has HTTP handlers to read & write arbitrary content to disk, and to execute any file on disk. It also has an SSH tunnel handler. The buildlet must never be exposed to the Internet. The coordinator provisions buildlets in one of three ways:
by creating VMs on Google Compute Engine (GCE) with custom images configured to fetch & run the buildlet on boot, listening on port 80 in a private network.
by running Linux containers (on either Google Kubernetes Engine or GCE with the Container-Optimized OS image), with the container images configured to fetch & run the buildlet on start, also listening on port 80 in a private network.
by taking buildlets out of a pool of connected, dedicated machines. The buildlet can run in either listen mode (as on GCE and GKE) or in reverse mode. In reverse mode, the buildlet connects out to https://farmer.golang.org/ and registers itself with the coordinator. The TCP connection is then logically reversed (using revdial and when the coordinator needs to do a build, it makes HTTP requests to the coordinator over the already-open TCP connection.
These three pools can be viewed at the coordinator's https://farmer.golang.org/#pools.
The env/ directory describes build environments. It contains scripts to create VM images, Dockerfiles to create Kubernetes containers, and instructions and tools for dedicated machines.
maintner in maintner/ is a library for slurping all of Go's GitHub and Gerrit state into memory. The daemon maintnerd in maintner/maintnerd/ runs on GKE and serves https://maintner.golang.org/. The daemon watches GitHub and Gerrit and appends to a mutation log whenever it sees new activity. The logs are stored on GCS and served to clients.
The godata package in maintner/godata/ provides a trivial API to let anybody write programs against Go's maintner corpus (all of our GitHub and Gerrit history), live up to the second. It takes a few seconds to load into memory and a few hundred MB of RAM after it downloads the mutation log from the network.
pubsubhelper in cmd/pubsubhelper/ is a dependency of maintnerd. It runs on GKE, is available at https://pubsubhelper.golang.org/, and runs an HTTP server to receive Webhook updates from GitHub on new activity and an SMTP server to receive new activity emails from Gerrit. It then is a pubsub system for maintnerd to subscribe to.
The gitmirror server in cmd/gitmirror/ mirrors Gerrit to GitHub, and also serves a mirror of the Gerrit code to the coordinator for builds, so we don't overwhelm Gerrit and blow our quota.
The Go gopherbot bot logic runs on GKE. The code is in cmd/gopherbot. It depends on maintner via the godata package.
The developer dashboard at https://dev.golang.org/ runs on GKE. Its code is in devapp/. It also depends on maintner via the godata package.
cmd/retrybuilds: a Go client program to delete build results from the dashboard
The perfdata server, in perfdata/appengine serves https://perfdata.golang.org/. It runs on App Engine and serves the benchmark result storage system.
The perf server, in perf/appengine serves https://perf.golang.org/. It runs on App Engine and serves the benchmark result analysis system. See its README for how to start a local testing instance.
If you wish to run a Go builder, please email golang-dev@googlegroups.com first. There is documentation at https://golang.org/wiki/DashboardBuilders, but depending on the type of builder, we may want to run it ourselves, after you prepare an environment description (resulting in a VM image) of it. See the env directory.