-
Notifications
You must be signed in to change notification settings - Fork 17.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmd/dist: include system metadata in build logs #50146
Comments
Change https://golang.org/cl/371475 mentions this issue: |
Change https://golang.org/cl/371474 mentions this issue: |
I took a look at the sharding code in the coordinator. Summary:
The last bullet means that it should be safe to have each dist execution print the metadata at startup. Since logs don't interleave, that metadata will be correct for all following tests until the next metadata block. This will look a bit ugly in the output, breaking the illusion that the log looks like a single unified run, but at least it will be accurate. |
Change https://golang.org/cl/372536 mentions this issue: |
Change https://golang.org/cl/372537 mentions this issue: |
Change https://golang.org/cl/372538 mentions this issue: |
For golang/go#50146. Change-Id: I44804be98159d9b1f3ba24b16c7a7fdc8fae97c5 Reviewed-on: https://go-review.googlesource.com/c/build/+/372536 Trust: Michael Pratt <mpratt@google.com> Run-TryBot: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Alex Rakoczy <alex@golang.org>
In preparation of supporting a longer test header, change parseOutputAndBanner to parseOutputAndHeader which returns the full human-readable header. The only behavior change is that output with only a banner and no trailing newline will still return the banner as part of the header. For golang/go#50146 Change-Id: Ie34fe3891e9bc29a3da79fddacd4829a89d2dbfb Reviewed-on: https://go-review.googlesource.com/c/build/+/372537 Reviewed-by: Alex Rakoczy <alex@golang.org> Trust: Michael Pratt <mpratt@google.com> Run-TryBot: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
Following CL 371474, cmd/dist may include a "Test execution environment" header which describes the test execution environment. When sharding tests, we want to surface the proper execution environment for each test, which may vary from shard to shard. We could simply print the metadata for each shard in its output, as shard results are printed in an atomic block. However, shards are pretty small and that adds quite a bit of noise to logs. Instead, treat the metadata block like the test header banners: as long as the metadata doesn't change, we don't need to print it again. On the other hand, if the metadata changes, we do print the test header banner again. This isn't strictly necessary, it just serves to improve readability by ensuring that tests are always immediately preceeded by their banner rather than metadata (in the case that metadata changes in the middle of a header block). This CL should be submitted and deployed before CL 371474. For golang/go#50146. Change-Id: Ifca30f7f31237fd8cd0fcd801d198d9c341f695e Reviewed-on: https://go-review.googlesource.com/c/build/+/372538 Trust: Michael Pratt <mpratt@google.com> Run-TryBot: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Alex Rakoczy <alex@golang.org>
Knowing whether test failures are correlated with specific CPU models on has proven useful on several issues. Log it for prior to testing so it is always available. internal/sysinfo provides the CPU model, but it is not available in the bootstrap toolchain, so we can't access this unconditionally in cmd/dist. Instead use a build-tagged file, as the final version of cmd/dist will use the final toolchain. The addition of new data to the beginning of cmd/dist output will break x/build/cmd/coordinator's banner parsing, leaving extra lines in the log output, though information will not be lost. https://golang.org/cl/372538 fixes up the coordinator and should be submitted and deployed before this CL is submitted. For #46272. For #49209. For #50146. Change-Id: I515d2ec58e4c0034b76bf624ecaab38f16146074 Reviewed-on: https://go-review.googlesource.com/c/go/+/371474 Trust: Benny Siegert <bsiegert@gmail.com> Reviewed-by: Benny Siegert <bsiegert@gmail.com> Trust: Michael Pratt <mpratt@google.com> Run-TryBot: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
Change https://golang.org/cl/378584 mentions this issue: |
Change https://golang.org/cl/378586 mentions this issue: |
Change https://golang.org/cl/378587 mentions this issue: |
Fails TestAllDependencies. This reverts CL 371475. For #50146. Change-Id: I1feccd772d92d80e57c6327a4ac7b8af753a8c05 Reviewed-on: https://go-review.googlesource.com/c/go/+/378586 Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org> Trust: Michael Pratt <mpratt@google.com> Run-TryBot: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
Fails TestRepeatBootstrap. This reverts CL 371474. For #50146. Change-Id: Ie4adda4e0229e153471301ca00fe2c1c694b4b2d Reviewed-on: https://go-review.googlesource.com/c/go/+/378587 Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org> Trust: Michael Pratt <mpratt@google.com> Run-TryBot: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
Change https://golang.org/cl/378589 mentions this issue: |
Change https://golang.org/cl/378590 mentions this issue: |
@prattmic Have you thought about what Go release this should target? Since the re-apply CL is ready, I'll tentatively put it into 1.19 milestone with early-in-cycle label, but please feel free to update further as needed. |
Knowing whether test failures are correlated with specific CPU models on has proven useful on several issues. Log it for prior to testing so it is always available. internal/sysinfo provides the CPU model, but it is not available in the bootstrap toolchain, so we can't access this in cmd/dist. Instead use a separate binary which cmd/dist will only build once testing begins. The addition of new data to the beginning of cmd/dist output will break x/build/cmd/coordinator's banner parsing, leaving extra lines in the log output, though information will not be lost. https://golang.org/cl/372538 fixes up the coordinator and should be submitted and deployed before this CL is submitted. This is a redo of CL 371474. It switches back to the original approach of using a separate binary, as the bootstap toolchain won't allow cmd/dist to import internal packages. For #46272. For #49209. For #50146. Change-Id: I906bbda987902a2120c5183290a4e89a2440de58 Reviewed-on: https://go-review.googlesource.com/c/go/+/378589 Reviewed-by: Austin Clements <austin@google.com> Trust: Michael Pratt <mpratt@google.com> Run-TryBot: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
Change https://go.dev/cl/411061 mentions this issue: |
We don't want to include the metadata command in the release. Exclude it. For golang/go#50146. Change-Id: I0e7c8b94afe07ffd8396d7bac1c039c972a1b855 Reviewed-on: https://go-review.googlesource.com/c/build/+/411061 Reviewed-by: Alex Rakoczy <alex@golang.org> Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
Knowing whether test failures are correlated with specific CPU models on has proven useful on several issues. Log it for prior to testing so it is always available. internal/sysinfo provides the CPU model, but it is not available in the bootstrap toolchain, so we can't access this unconditionally in cmd/dist. Instead use a build-tagged file, as the final version of cmd/dist will use the final toolchain. The addition of new data to the beginning of cmd/dist output will break x/build/cmd/coordinator's banner parsing, leaving extra lines in the log output, though information will not be lost. https://golang.org/cl/372538 fixes up the coordinator and should be submitted and deployed before this CL is submitted. For golang#46272. For golang#49209. For golang#50146. Change-Id: I515d2ec58e4c0034b76bf624ecaab38f16146074 Reviewed-on: https://go-review.googlesource.com/c/go/+/371474 Trust: Benny Siegert <bsiegert@gmail.com> Reviewed-by: Benny Siegert <bsiegert@gmail.com> Trust: Michael Pratt <mpratt@google.com> Run-TryBot: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
As a follow-up to https://golang.org/cl/371474, add the OS version to the metadata printed for each test. Fixes golang#50146. Change-Id: I3b7e47983d0e85feebce8e424881b931882d53bf Reviewed-on: https://go-review.googlesource.com/c/go/+/371475 Reviewed-by: Bryan Mills <bcmills@google.com> Trust: Michael Pratt <mpratt@google.com> Run-TryBot: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
Fails TestAllDependencies. This reverts CL 371475. For golang#50146. Change-Id: I1feccd772d92d80e57c6327a4ac7b8af753a8c05 Reviewed-on: https://go-review.googlesource.com/c/go/+/378586 Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org> Trust: Michael Pratt <mpratt@google.com> Run-TryBot: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
Fails TestRepeatBootstrap. This reverts CL 371474. For golang#50146. Change-Id: Ie4adda4e0229e153471301ca00fe2c1c694b4b2d Reviewed-on: https://go-review.googlesource.com/c/go/+/378587 Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org> Trust: Michael Pratt <mpratt@google.com> Run-TryBot: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
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:
internal/testenv
and manually print fromTestMain
in particularly important packages. This has less coverage, but we could instrument the most crashy packages (likeruntime
).testing
itself, always printing the metadata on aGOEXPERIMENT
?cc @golang/release @bcmills @aclements
The text was updated successfully, but these errors were encountered: