The TestFailures page contains links to help file a new bug about tests that are failing. If a bug already exists for the failures, this is just encouraging people to file duplicates. It would be a lot better if the TestFailures page could link to existing bugs when they exist instead of showing the new bug link.
The tricky thing is identifying the existing bugs. Ryosuke pointed out that we could use test_expectations.txt files for bots that use them. (Of course, right now I don't think the TestFailures page shows information for any such bots.)
At a bare minimum we could just show the links to existing bugs alongside the new bug link. That way the user could determine if there is already an appropriate bug filed, rather than TestFailures trying to figure that out for you.
Let's use this bug to cover showing the existing bugs. We can file a separate bug to remove the new bug link when we detect it isn't needed, if we decide that would be desirable.
Created attachment 98190 [details] Add links to existing bugs related to failing tests on TestFailures page
Created attachment 98191 [details] Screenshot of the new layout
Created attachment 98194 [details] Add links to existing bugs related to failing tests on TestFailures page
Comment on attachment 98190 [details] Add links to existing bugs related to failing tests on TestFailures page View in context: https://bugs.webkit.org/attachment.cgi?id=98190&action=review > Tools/BuildSlaveSupport/build.webkit.org-config/public_html/TestFailures/Utilities.js:54 > +function addParametersToURL(url, queryParameters) { I'm not sure if parameter is a good name since it's usually called query part of the URL. Maybe addQueryToURL or addQueryPartToURL?
Comment on attachment 98190 [details] Add links to existing bugs related to failing tests on TestFailures page View in context: https://bugs.webkit.org/attachment.cgi?id=98190&action=review >> Tools/BuildSlaveSupport/build.webkit.org-config/public_html/TestFailures/Utilities.js:54 >> +function addParametersToURL(url, queryParameters) { > > I'm not sure if parameter is a good name since it's usually called query part of the URL. Maybe addQueryToURL or addQueryPartToURL? How about addQueryParametersToURL? That's what my fingers kept wanting to type anyway.
(In reply to comment #8) > (From update of attachment 98190 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=98190&action=review > > >> Tools/BuildSlaveSupport/build.webkit.org-config/public_html/TestFailures/Utilities.js:54 > >> +function addParametersToURL(url, queryParameters) { > > > > I'm not sure if parameter is a good name since it's usually called query part of the URL. Maybe addQueryToURL or addQueryPartToURL? > > How about addQueryParametersToURL? That's what my fingers kept wanting to type anyway. SGTM.
Updated build.webkit.org Committed r89447: <http://trac.webkit.org/changeset/89447>
View in context: https://bugs.webkit.org/attachment.cgi?id=98190&action=review I know this landed, but I had a tab open with this comment. Not important or worthy of a separate commit. > Tools/BuildSlaveSupport/build.webkit.org-config/public_html/TestFailures/Utilities.js:56 > + return key + '=' + encodeURIComponent(queryParameters[key]) Nit (style): normally you use semicolons.
(In reply to comment #11) > View in context: https://bugs.webkit.org/attachment.cgi?id=98190&action=review > > I know this landed, but I had a tab open with this comment. Not important or > worthy of a separate commit. > > > Tools/BuildSlaveSupport/build.webkit.org-config/public_html/TestFailures/Utilities.js:56 > > + return key + '=' + encodeURIComponent(queryParameters[key]) > > Nit (style): normally you use semicolons. Whoops! Will fix.
Whoops, this isn't working due to cross-site XHR restrictions :-(
Bill Siegrist is going to add some Access-Control headers to bugs.webkit.org to allow the XHRs to go through. Thanks, Bill!