x/build: missing LUCI TryBot coverage for x/telemetry

[bcmills]

Go version

9819d82

Output of go env in your module/workspace:

N/A

What did you do?

See #65544.

What did you see happen?

https://go.dev/cl/560462 had a TryBot+1 vote from LUCI, but introduced deterministic failures on two first class ports (linux/386 and windows/386).

What did you expect to see?

I expect all user-facing x/ repos to have TryBots configured for at least all of the first class ports that have scalable builders.

[findleyr]

If possible, I think x/telemetry should also have a number of misc-compile builders for platforms where it may be dormant but still needs to compile. Is that something we can easily add in LUCI?

[findleyr]

We discussed this in the telemetry meeting, and came to a consensus that x/telemetry should have essentially the same set of builders as the Go repo.

No need to downgrade any platforms to misc-compile: if TryBots run on the Go repo, it should run on x/telemetry.

[mknyszek]

I think both the request in this issue and the follow-on request to run all Go repo presubmit bots should be very straightforward to do.

[findleyr]

CC @golang/telemetry

[mknyszek]

Amusingly, this required changing a single line of configuration. :)

[gopherbot]

Change https://go.dev/cl/562536 mentions this issue: main.star: mark x/telemetry as a PT.CORE repository

[hyangah]

Question - does this make x/telemetry/godev module run in all core platforms?

[mknyszek]

I believe so. If you're asking because you'd like to opt-out that module, we don't really have an easy way to opt-out certain modules from certain platforms yet, but it also doesn't sound too hard to build. It would just take longer to get there.

[findleyr]

it also doesn't sound too hard to build. It would just take longer to get there.

We can skip tests manually for now, but it would be really useful if there were an easy way to customize builders per module. For example, x/tools/gopls does not need to run on Android, and x/pkgsite does not need to run on anything but linux (but x/pkgsite/cmd/pkgsite will need to run on everything).

[mknyszek]

Here's the gist of the extra work required.

The build "script" (golangbuild) controls module discovery and test execution on those modules. Builder configurations are repo-level, so the "script" needs to be told what to do. Perhaps the repo is by default tested on all platforms, and all modules get tested on all platforms by default. However, in the builder configuration, you can list modules as well as a platform allowlist.

Concrete implementation steps:

1. Add a new property to golangbuild's input properties that is a mapping from module name to a list of platforms.
2. During golangbuild's module discovery, if a module with a matching name is discovered, we check the current platform against the allowlist to decide whether to execute the tests.
3. Our configuration needs to be extended define this submodule mapping on a per-repo basis. That mapping is then copied to the subrepo builders' properties.

Leaving this for either a release rotation member or if someone from the tools team wants to take a stab at it, since I don't think I'll have time to work on this until at least after the migration.

Happy to help guide anyone through the process and share knowledge. This would be a decent starter project for getting more familiar with some of the LUCI specifics.

[gopherbot]

Change https://go.dev/cl/563358 mentions this issue: godev/cmd/telemetrygodev: skip tests in unintended environments