You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@rsc, how is this a Go1.6 issue? It's not released with Go.
In any case, it's not exactly clear how this should work. Should a flake make it fire? Do you need N failures in a row first? What if the N failures in a row are different? How do you detect they're different? Parsing the text?
The easiest thing is to ignore flakes and just say any transition from ok to failure emails.
I suppose the coordinator could poll http://build.golang.org/?mode=json occasionally and post to Gerrit (which emails), since the coordinator already can post to Gerrit. By asking for the data from build.golang.org it would also catch builders like old-style builders like netbsd and solaris, which report directly to build.golang.org.
I'd prefer if people just don't break the build, though, so I've been spending my builder time primarily on making trybots better.
I'm happy to review code to resurrect this, though. I'm not sure where it lives before, or if it even makes sense to reuse any of the code. @adg?
In any case, it's not exactly clear how this should work. Should a flake
make it fire? Do you need N failures in a row first? What if the N failures
in a row are different? How do you detect they're different? Parsing the
text?
The easiest thing is to ignore flakes and just say any transition from ok
to failure emails.
I suppose the coordinator could poll http://build.golang.org/?mode=json
occasionally and post to Gerrit (which emails), since the coordinator
already can post to Gerrit. By asking for the data from build.golang.org
it would also catch builders like old-style builders like netbsd and
solaris, which report directly to build.golang.org.
I'd prefer if people just don't break the build, though, so I've been
spending my builder time primarily on making trybots better.
I'm happy to review code to resurrect this, though. I'm not sure where it
lives before, or if it even makes sense to reuse any of the code. @adg https://github.com/adg?
—
Reply to this email directly or view it on GitHub #12509 (comment).
This could even be in cmd/gopherbot (which is easy to hack on locally), looking at the build.golang.org failure results and trying to not spam too early and waiting until it's confident (e.g. make.bash failing is a real failure, but a test failure might be a flake unless we saw in N times in a row).
Look at x/build/cmd/retrybuilds for code that accesses the build.golang.org failure results.
Activity
rsc commentedon Oct 23, 2015
Sure would be nice!
bradfitz commentedon Oct 30, 2015
@rsc, how is this a Go1.6 issue? It's not released with Go.
In any case, it's not exactly clear how this should work. Should a flake make it fire? Do you need N failures in a row first? What if the N failures in a row are different? How do you detect they're different? Parsing the text?
The easiest thing is to ignore flakes and just say any transition from ok to failure emails.
I suppose the coordinator could poll http://build.golang.org/?mode=json occasionally and post to Gerrit (which emails), since the coordinator already can post to Gerrit. By asking for the data from build.golang.org it would also catch builders like old-style builders like netbsd and solaris, which report directly to build.golang.org.
I'd prefer if people just don't break the build, though, so I've been spending my builder time primarily on making trybots better.
I'm happy to review code to resurrect this, though. I'm not sure where it lives before, or if it even makes sense to reuse any of the code. @adg?
adg commentedon Oct 30, 2015
The code is already there in the build dashboard, it's just broken and I
haven't had an opportunity to investigate why.
On 31 October 2015 at 03:25, Brad Fitzpatrick notifications@github.com
wrote:
rsc commentedon Dec 5, 2015
Would still like this, and it would have potentially sped the work on Go 1.6, but too late now and obviously not going to gate Go 1.6.
[-]build: bring back "broke the build" notifications[/-][+]x/build: bring back "broke the build" notifications[/+]josharian commentedon Mar 28, 2018
cc @andybons
andybons commentedon Mar 30, 2018
Indeed this would be nice.
FiloSottile commentedon May 15, 2018
This would be useful both for the dev branches and for the subrepos (so we are notified when master breaks x/crypto or x/crypto breaks on 1.9).
bradfitz commentedon Sep 4, 2019
This could even be in cmd/gopherbot (which is easy to hack on locally), looking at the build.golang.org failure results and trying to not spam too early and waiting until it's confident (e.g. make.bash failing is a real failure, but a test failure might be a flake unless we saw in N times in a row).
Look at x/build/cmd/retrybuilds for code that accesses the build.golang.org failure results.
/cc @toothrot
gopherbot commentedon Nov 21, 2019
Change https://golang.org/cl/208322 mentions this issue:
app/appengine: delete old "broke the build" code
app/appengine: delete old "broke the build" code