x/build: run platform/arch specific builders when platform/arch constrained files are changed

[rolandshoemaker]

When making changes to platform or arch constrained files (.go/.s) it would be nice for LUCI to automatically include builders of those types in the set that is run. Currently this has to be done manually, which is not always particularly obvious, and can lead to changes appearing to pass builders when they would fail in the specific builders were included.

This doesn't seem to be easily done with location filters regexps in the luci main.star, since we want to be more specific when there is a platform suffix (e.g. if example_linux_amd64.go changes, we only want to run the linux-amd64 builder), and less specific when there is only an arch suffix (e.g. if example_amd64.go changes, we want to run all of the amd64 builders). I fiddled around with this and couldn't find an obvious way to accomplish it.

One possible option is to add a special mode to golangbuild which scans the file names changed in a CL, and does this matching itself, spawning an additional set of builders.

Ideally we'd also do this for build constrained files which use the //go:build syntax, but this seems a lot more complex, as it's not particularly easy to extract this information via the gerrit API (as far as I can tell). For a first pass, it'd probably be fine to just do the file name based approach, since that covers the majority of use cases.

cc @golang/release

[rolandshoemaker]

One note, when I say "we want to run all of the amd64 builders" for the example_amd64.go case, we may actually want to only run a slightly expanded subset over the defaults, but where to strike the balance between testing things haven't broken, and reducing the cost of testing a CL, is hard to determine.

[dmitshur]

To connect some dots: in #66009, @mknyszek has a paragraph that mentions a "proxy" builder, which is similar (if not identical) to the "spawning an additional set of builders" description here.

At a high level, this issue sounds like "partially automate SlowBot requests". One important consideration of doing SlowBot selection automatically is deciding whether the change warrants potentially waiting a long time for a low-capacity (or possibly missing) slowbot, or whether it should only consider high-capacity builders in scope.

One more consideration: depending on whether this is intended for CLs we're mostly sending ourselves (and we can rely more on client-side-only helpers), or more broadly any CL anyone makes (where we can only rely on server-side checks), another option to consider might be something in git-codereview's pre-commit hooks. That hook is already written in Go, so it could look at the .go files being modified and compute a Cq-Include-Trybots footer to add next to the Change-Id footer it already adds. This has some upsides like being able to modify the Cq-Include-Trybots as part of the code review.