Description
We've had two issues very recently (#49209, #46272) that only occurred on specific CPU models, and a third (#49065) that occurred only on upgrade to a new kernel version. All of these took quite a while to narrow down to the specific property.
Neither of these properties are indicated anywhere in the build logs, so manual reproduction (or new builders) were required to see if there was any correlation. I'd like to include the CPU model, OS version, and perhaps additional future metadata in build output so that we have a chance to notice such correlations in the future.
This is also something I think we'd want included in structured build output (#37486).
I have a prototype MVP implementation of this in https://golang.org/cl/371474 and https://golang.org/cl/371475. These add a "test" to cmd/dist which prints the metadata. This avoids bootstrapping issues with cmd/dist, but isn't the cleanest.
This approach may be problematic w.r.t. test sharding. This test will (I think?) run only on a single shard, but other shards may not have the same CPU and/or OS version. Even if we run on each shard, we'd need to know which tests ran on which shard when correlating failures.
Alternatives either @bcmills or I have thought of:
- Add this as a helper in
internal/testenv
and manually print fromTestMain
in particularly important packages. This has less coverage, but we could instrument the most crashy packages (likeruntime
). - Add this to
testing
itself, always printing the metadata on aGOEXPERIMENT
? - Integrate fully into cmd/dist with bootstrap toolchain support to print every time. We still need a way to connect the dots between shards. Maybe this is already possible? I'm not very familiar with our test sharding.
cc @golang/release @bcmills @aclements