-
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: trybots should include all platforms that can contribute release-blockers #29239
Comments
If we consider breaking the platform to be a release-blocking bug, then I agree it should be run on every trybot run triggered by a CL. That said, for builders that we can't spin up arbitrary instances of like the IBM Z-series, it could create a bottleneck for all runs across every CL. One thing we could do (though it's not a trivial task) is create a submit queue that requires all builders across first-class ports to succeed and if they do, the patch gets submitted. So intermediate runs during review are a smaller subset that run quicker but the final submission would catch this sort of issue. @bradfitz did we ever have email alerts when a builder failed? Is there precedent for adding them? |
A submit queue would also ensure that syntactically-but-not-semantically merge conflicts don't break builds. |
We could batch up TryBot changes on those platforms: pile up all of the changes that need TryBot testing in a queue, and have a single TryBot run test all of the changes in the queue as a batch. (The downside to that approach, of course, is a higher false-positive rate, or the need to break up the batch and retry failing tests individually in case of regressions.) |
Slowbots (#34501) are now live. Of the first class ports (the ones that we define as being release blockers), the two we're missing as trybots are linux/arm and darwin/amd64. We used to have both of those but they were too unreliable. Things we can improve that would satisfy this bug, probably in this order:
|
If a build failure for a given platform P can be considered a release-blocker (such as #29221), then trybots should also run on P. Otherwise we have to rely on the actual build failure before we can fix the issue.
Example: In #29221, some newly added math tests failed on s390x, yet the trybots didn't notice.
If it's too expensive (too slow) to run the trybots for some platforms all the time, maybe we could consider doing it at least some time before any of the imminent release stages. For instance, if we are planning to cut a Beta or RC, we might want to consider starting to run the trybots a week before on all platforms where failures might block the release.
cc: @golang/osp-team
cc: @bradfitz
cc: @dmitshur
cc: @andybons
The text was updated successfully, but these errors were encountered: