| Summary: | Add webkit-patch command to crawl buildbot history and find when tests started to fail | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Eric Seidel (no email) <eric> | ||||||||
| Component: | New Bugs | Assignee: | Nobody <webkit-unassigned> | ||||||||
| Status: | RESOLVED FIXED | ||||||||||
| Severity: | Normal | CC: | abarth, abecsi, aroben, jchaffraix, ossy | ||||||||
| Priority: | P2 | ||||||||||
| Version: | 528+ (Nightly build) | ||||||||||
| Hardware: | Other | ||||||||||
| OS: | OS X 10.5 | ||||||||||
| Bug Depends on: | |||||||||||
| Bug Blocks: | 37063 | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Eric Seidel (no email)
2010-03-31 17:50:55 PDT
Created attachment 52228 [details]
Patch
+ raise "Unhandled title: %s" % str(table_title) We should only be raising Exception objects. Better to raise an Exception(). + def _print_blame_information_for_commit(tool, commit_info): This should be in a base class? Maybe on CommitInfo? Having a random global function seems strange. + class FailureReason(AbstractDeclarativeCommand): This class is kind of lame. It makes it really hard to re-use this logic or to test it. Maybe we need a FailureWalker class? Created attachment 52696 [details]
First Try
Updated it so it applies to TOT. Haven't bothered to abstract out the build-walker stuff. Created attachment 52704 [details]
Patch
Comment on attachment 52704 [details]
Patch
Ok. Let's take this as a starting point. As you noted in the other bug, there's a lot of overlap with the algorithm the sheriff uses to track recent regressions. This code looks like it understands more cases (e.g., >= 20 failures). We should find a way to unify and abstract out the different pieces,but I don't want to hold this patch hostage any longer.
Committed r57195: <http://trac.webkit.org/changeset/57195> |