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

Open
griesemer opened this Issue Dec 13, 2018 · 5 comments

Comments

Projects
None yet
5 participants
@griesemer
Copy link
Contributor

griesemer commented Dec 13, 2018

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: @go-osp-team
cc: @bradfitz
cc: @dmitshur
cc: @andybons

@andybons andybons added this to the Unreleased milestone Dec 13, 2018

@andybons andybons changed the title trybot: should run on all platforms that can contribute release-blockers x/build: trybots should include all platforms that can contribute release-blockers Dec 13, 2018

@gopherbot gopherbot added the Builders label Dec 13, 2018

@andybons

This comment has been minimized.

Copy link
Member

andybons commented Dec 14, 2018

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?

@bradfitz

This comment has been minimized.

Copy link
Member

bradfitz commented Dec 14, 2018

@bradfitz did we ever have email alerts when a builder failed? Is there precedent for adding them?

Yes. That is #12509. (You even commented on it. :))

@bradfitz

This comment has been minimized.

Copy link
Member

bradfitz commented Dec 14, 2018

A submit queue would also ensure that syntactically-but-not-semantically merge conflicts don't break builds.

@bcmills

This comment has been minimized.

Copy link
Member

bcmills commented Dec 14, 2018

for builders that we can't spin up arbitrary instances of like the IBM Z-series, it could create a bottleneck

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.)

@bradfitz

This comment has been minimized.

Copy link
Member

bradfitz commented Dec 14, 2018

TryBots are supposed to be fast, though.

If we want the SlowBots, that is more #24539 and ... another bug I can't find right now about letting users pick which trybots to run instead of the default set.

For submit queue, that is basically #12482 combined with #9858.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment