Dashboard metrics page should have EWS statistics

[Alexey Proskuryakov]

Otherwise, how do we know it when we improve things.

The UI is much more challenging than one for regular bots though, for multiple reasons:
- EWS logic is a mystery to most, so we need to explain what any number means.
- EWS is interactive, so patch processing result depends not just on EWS and the patch, but also on what happened with the bug and with trunk in the meanwhile. The patch could be obsoleted, or it could cease to apply because something else was landed while it was being processed.
- There is a lot less publicly visible history, so we need to present more troubleshooting information.

[Alexey Proskuryakov]

Also because we can't hide any platforms - everyone looks at all platforms for EWS.

[Alexey Proskuryakov]

Created attachment 239655 [details]
proposed patch

So the result is a sizable chunk of text for each queue, e.g.:

mac-wk2

96% of patches had final results at first try. Time to result:
- median: 47 minutes;
- average: 43 minutes.
This includes 8% that did not apply to trunk.

2% of patches ceased to be eligible for processing before the first try finished.

2% of patches had to be retried, including 2% that kept being retried until the patch became ineligible for processing.

Median wait time before processing started: less than a minute.

[WebKit Commit Bot]

Attachment 239655 [details] did not pass style-queue:


ERROR: Tools/QueueStatusServer/handlers/processingtimesjson.py:61:  whitespace before '}'  [pep8/E202] [5]
ERROR: Tools/QueueStatusServer/handlers/processingtimesjson.py:66:  [ProcessingTimesJSON.get] Instance of 'ProcessingTimesJSON' has no 'response' member  [pylint/E1101] [5]
ERROR: Tools/QueueStatusServer/handlers/processingtimesjson.py:67:  [ProcessingTimesJSON.get] Instance of 'ProcessingTimesJSON' has no 'response' member  [pylint/E1101] [5]
ERROR: Tools/QueueStatusServer/handlers/processingtimesjson.py:72:  [ProcessingTimesJSON.get] Instance of 'ProcessingTimesJSON' has no 'response' member  [pylint/E1101] [5]
Total errors found: 4 in 10 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Ryosuke Niwa]

Comment on attachment 239655 [details]
proposed patch

View in context: https://bugs.webkit.org/attachment.cgi?id=239655&action=review

> Tools/BuildSlaveSupport/build.webkit.org-config/public_html/dashboard/Scripts/BubbleQueueServer.js:-34
> +        "gtk-wk2-ews": {platform: Dashboard.Platform.LinuxGTK, shortName: "gtk-wk2", title: "WebKit2\xa0Release\xa0Build\xa0EWS"},
>          "mac-ews": {platform: Dashboard.Platform.MacOSXMountainLion, shortName: "mac", title: "WebKit1\xa0Release\xa0Tests\xa0EWS"},
>          "mac-wk2-ews": {platform: Dashboard.Platform.MacOSXMountainLion, shortName: "mac-wk2", title: "WebKit2\xa0Release\xa0Tests\xa0EWS"},
>          "win-ews": {platform: Dashboard.Platform.Windows7, shortName: "win", title: "WebKit1\xa0Release\xa0Build\xa0EWS"},
> -        "gtk-wk2-ews": {platform: Dashboard.Platform.LinuxGTK, shortName: "gtk-wk2", title: "WebKit2\xa0Release\xa0Build\xa0EWS"},

Why are you moving GTK+ here?

> Tools/QueueStatusServer/handlers/processingtimesjson.py:55
> +            if not entry.attachment_id in result:
> +                result[entry.attachment_id] = {}

result.setdefault(entry.attachment_id, {})

> Tools/QueueStatusServer/handlers/processingtimesjson.py:66
> +        self.response.headers["Access-Control-Allow-Origin"] = "*"

Should we use *.webkit.org & *.apple.com instead?

[Alexey Proskuryakov]

> Why are you moving GTK+ here?

Mentioned that in ChangeLog, it's to match the order of bubbles in Bugzilla.

> > Tools/QueueStatusServer/handlers/processingtimesjson.py:66
> > +        self.response.headers["Access-Control-Allow-Origin"] = "*"
> 
> Should we use *.webkit.org & *.apple.com instead?

We could, although not as easily. I don't think that it matters though.

[Alexey Proskuryakov]

Committed <http://trac.webkit.org/r174622>.