Skip to content

cmd/dist: include system metadata in build logs #50146

Closed
@prattmic

Description

@prattmic

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 from TestMain in particularly important packages. This has less coverage, but we could instrument the most crashy packages (like runtime).
  • Add this to testing itself, always printing the metadata on a GOEXPERIMENT?
  • 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

Metadata

Metadata

Assignees

No one assigned

    Labels

    Buildersx/build issues (builders, bots, dashboards)FrozenDueToAgeNeedsFixThe path to resolution is known, but the work has not been done.early-in-cycleA change that should be done early in the 3 month dev cycle.

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions