| commit | 351ffdab4a5a0f102cc6c1811e7c1f681075eddd | [log] [tgz] |
|---|---|---|
| author | Dmitri Shuralyov <dmitshur@golang.org> | Thu May 13 11:54:20 2021 -0400 |
| committer | Dmitri Shuralyov <dmitshur@golang.org> | Mon May 17 23:53:43 2021 +0000 |
| tree | 3176ca7da1d6311e28e43b10e7370068f2fa352f | |
| parent | d36eef7e29e5a51160492e873e956f0471c0cb9f [diff] |
cmd/coordinator, maintner/maintnerd/maintapi: consolidate TryBot branch logic This change reverts the coordinator side to be much simpler, as it was before CL 167382, and consolidates all the version selection in maintapi. This direction is chosen because at this time¹ maintapi is best suited to perform version selection. This is a refactor CL that leaves current behavior unmodified, and test cases provide improved coverage. The following smaller CL will make the desired changes to behavior. Remove TestNewTrySetBuildRepoGo110 because it's no longer needed. It was added when x/build started requiring module mode to build successfully, given that Go 1.10 didn't have module mode support. Background At this time¹ coordinator makes use of maintapi to find TryBot work, and it is a collaborate effort between the two components that results in determining what builds will happen. Coordinator is ultimately responsible for starting and running the builds, but it doesn't have information about the branches in the Go project (the Go revision at refs/heads/master, refs/heads/release-branch.go1.16, etc.). Maintapi has that information via the maintner corpus. So it makes the version information available to coordinator by populating relevant fields in apipb.GoFindTryWorkResponse. Issue golang/go#28891 was about wanting to test golang.org/x repo CLs on release-branch.go1.n with the corresponding Go 1.n version, rather than Go tip. Unfortunately, it was implemented on the coordinator side, resulting in the logic for version selection to be more spread between the coordinator and maintapi components. There were followup issues like golang/go#42127 and golang/go#37512, whose fixes built on top of the coordinator side, and increased complexity there. As a consequence, making and testing further changes became more difficult than it needs to be. ¹ After golang/go#34744 is done, I'd like to move all the TryBot version selection logic into coordinator, the component responsible for TryBots. But not today. For golang/go#46154. Change-Id: I93986acefd4bf66b27ccf0323439966122b7989a Reviewed-on: https://go-review.googlesource.com/c/build/+/319789 Trust: Dmitri Shuralyov <dmitshur@golang.org> Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Carlos Amedee <carlos@golang.org>
This subrepository holds the source for various packages and tools that support Go's build system and the development of the Go programming language.
This repository uses Gerrit for code changes. To contribute, see https://golang.org/doc/contribute.html.
The main issue tracker for the blog is located at https://github.com/golang/go/issues. Prefix your issue with “x/build/DIR: ” in the subject line.
The main components of the Go build system are:
The dashboard, in app/, serves https://build.golang.org/. It runs on App Engine and holds the state for which builds passed or failed, and stores the build failure logs for post-submit failures. (Trybot build failure logs are stored elsewhere). The dashboard does not execute any builds on its own.
The coordinator, in cmd/coordinator/, serves https://farmer.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.
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 http://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
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.