-
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
x/build/cmd/coordinator: include -longtest and -race builders for trybots on release branches #37827
Comments
Change https://golang.org/cl/234531 mentions this issue: |
Change https://golang.org/cl/235337 mentions this issue: |
Change https://golang.org/cl/235338 mentions this issue: |
This test data will be modified to match a change in behavior in the next commit. Update it to a supported Go version first. For golang/go#37827. Change-Id: I83ad967a11f0fdde454edc541e9a8e7cf061f0e0 Reviewed-on: https://go-review.googlesource.com/c/build/+/235337 Run-TryBot: Dmitri Shuralyov <[email protected]> TryBot-Result: Gobot Gobot <[email protected]> Reviewed-by: Carlos Amedee <[email protected]> Reviewed-by: Alexander Rakoczy <[email protected]>
The goal of this test policy change is to decrease the chance of a Go repository release branch from getting into a state where some longtest post-submit builders are failing, as this will interfere with the ability to issue releases after golang/go#29252 is fixed. There are not that many CLs sent to release branches, so the extra latency caused by slower longtest builders being a part of trybots should not be very disruptive. For golang/go#37827. For golang/go#29252. Change-Id: I819b120bb7b763df4acf4583375cdb840793d323 Reviewed-on: https://go-review.googlesource.com/c/build/+/235338 Run-TryBot: Dmitri Shuralyov <[email protected]> TryBot-Result: Gobot Gobot <[email protected]> Reviewed-by: Alexander Rakoczy <[email protected]> Reviewed-by: Carlos Amedee <[email protected]>
CL 235338 is deployed now. I tried it in an empty CL on release-branch.go1.13 (see here) and the amd64 longtest builders are working as expected, but linux-386-longtest is failing in a strange way:
This is strange and needs investigation. We've seen this problem happen in other builders, e.g., #33598. /cc @bcmills |
Making the tree slightly different has allowed the linux-386-longtest builder to start properly. |
The goal of this change is to reduce the chance of issuing a release with an unintended regression that would be caught by running long tests. This change adds long tests that are run during the -prepare step, in addition to all the existing short tests that are run. Executing the long tests is implemented by adding two new test-only release targets. For a release to be considered complete, all release targets must complete. These test-only targets are built only for the purpose of verifying their tests succeed, or to block the release otherwise. They do not produce release artifacts. The new test-only targets are named after the builder which is used to perform their tests, and they are: • linux-amd64-longtest • windows-amd64-longtest More builders may be added in the future, but care must be taken to ensure the test execution environment is as close as possible to that of build.golang.org post-submit builders, in order to avoid false positives and false negatives. As part of a gradual rollout, this change also adds a flag to skip longtest builders. It's meant to be used in case a long test proves to be flaky, and enough confidence can be gained through testing elsewhere that the failure is not a regression caused by a change merged to the release branch. For now, its default value includes both longtest builders, so they are currently opt-in and this CL is a no-op. After testing proves that it is viable to rely on this (and any issues preventing that from being possible are resolved), the default value of the flag will be changed to the empty string. For golang/go#29252. For golang/go#39054. For golang/go#37827. Fixes golang/go#24614. Change-Id: I33ea6601aade2873f857c63f00a0c11821f35a95 Reviewed-on: https://go-review.googlesource.com/c/build/+/234531 Run-TryBot: Dmitri Shuralyov <[email protected]> TryBot-Result: Gobot Gobot <[email protected]> Reviewed-by: Carlos Amedee <[email protected]> Reviewed-by: Alexander Rakoczy <[email protected]>
Change https://go.dev/cl/456043 mentions this issue: |
From the dashboard, it seems the linux-arm64-longtest builder has been working reasonably well for a while. At this point we don't have known issues for it. So remove known issues. Enable it for trybot on 1.20+ release branches, per golang/go#37827. Only for 1.20+ because it is failing on older versions of Go. Fixes golang/go#49649. Updates golang/go#53851, golang/go#37827. Change-Id: I682aa4028b791ecd80360fbe05ef615dad19405d Reviewed-on: https://go-review.googlesource.com/c/build/+/456043 Reviewed-by: Dmitri Shuralyov <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Run-TryBot: Cherry Mui <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]>
Change https://go.dev/cl/492055 mentions this issue: |
The darwin longtest builder was added during the Go 1.21 dev cycle and needed some development work before it would pass all tests. Disable it on older release branches that don't have said work, and make it run on Go 1.21 and newer release branches as a TryBot like all other longtest builders. This makes it consistent with other -longtest builders and will help avoid entering broken state when backporting to future release branches. Also remove redundant version check from windows longtest tryBot policy functions since the version check is already there in buildsRepo policy. For golang/go#35678. For golang/go#37827. Change-Id: I09c479f1be2b3635c385b504b0c86b50e65e696b Reviewed-on: https://go-review.googlesource.com/c/build/+/492055 TryBot-Result: Gopher Robot <[email protected]> Auto-Submit: Dmitri Shuralyov <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]> Reviewed-by: Michael Pratt <[email protected]> Run-TryBot: Dmitri Shuralyov <[email protected]>
Change https://go.dev/cl/510699 mentions this issue: |
The darwin-amd64-longtest builder is configured to run as a TryBot on release branches since darwin/amd64 is a first class port, and usually it's better to prioritize not breaking the release branch over CL submission speed. However, all other -longtest builders that run as automatic TryBots on release branches have capacity for sharding, while this one only runs with one shard, making it very slow and frustrating to wait for. This will be felt even more during the early thaw. So convert it back to be optional SlowBot for now, and rely on it reporting problems via post-submit results only. For golang/go#37827. Change-Id: I68b2a1793c5334032ebbc6fa73d305e899e2e2d6 Reviewed-on: https://go-review.googlesource.com/c/build/+/510699 Reviewed-by: Heschi Kreinick <[email protected]> TryBot-Result: Gopher Robot <[email protected]> Reviewed-by: Carlos Amedee <[email protected]> Run-TryBot: Dmitri Shuralyov <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]> Auto-Submit: Dmitri Shuralyov <[email protected]>
Change https://go.dev/cl/522175 mentions this issue: |
Given release branches only get backports and true development should be happening on the main branch, release branches prioritize catching more problems before submission over pre-submit completion speed, and so they choose not to skip longtest and race builders. This is a part of the current trybot policy implemented in x/build, and seems to be generally working well. For golang/go#37827. Change-Id: I1c9bcf600a7ea5da32296a8ddfcda083da839c29 Reviewed-on: https://go-review.googlesource.com/c/build/+/522175 Reviewed-by: Heschi Kreinick <[email protected]> TryBot-Bypass: Dmitri Shuralyov <[email protected]> Auto-Submit: Dmitri Shuralyov <[email protected]> Reviewed-by: Dmitri Shuralyov <[email protected]>
After a major version of a Go release is out, we send relatively few CLs to the release branch in order to backport fixes for minor releases, per https://golang.org/wiki/MinorReleases policy.
We should consider including -longtest and -race builders in the default tryset (set of builders included in a normal trybot run) for those branches::
Those builders already run as post-submit builders, but also running them during trybots will give us more information to work with before a CL is submitted to a release branch.
We may want to do this only for minor releases, i.e., after a major Go release is out. Or we can do this always, which would include CLs sent to a release branch after the first release candidate is made.
An existing alternative is to manually request those builders via SlowBots.
/cc @cagedmantis @toothrot @golang/osp-team
The text was updated successfully, but these errors were encountered: