RESOLVED FIXED 204386
run-javascriptcore-tests: Hide the output of binaries behind --verbose
https://bugs.webkit.org/show_bug.cgi?id=204386
Summary run-javascriptcore-tests: Hide the output of binaries behind --verbose
Jonathan Bedard
Reported 2019-11-19 16:42:47 PST
Aakash pointed out that we might have way too many logs coming out of run-javascriptcore-tests by default. We should gate some of these logs on the --verbose flag.
Attachments
Patch (1.59 KB, patch)
2019-11-19 16:47 PST, Jonathan Bedard
no flags
Jonathan Bedard
Comment 1 2019-11-19 16:47:26 PST
Aakash Jain
Comment 2 2019-11-21 09:22:36 PST
Comment on attachment 383921 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=383921&action=review > Tools/Scripts/run-javascriptcore-tests:585 > + print "$subTestName failed\n" if ($failureFlag && !$verbose); Shouldn't we print the failures irrespective of verbose flag. Hiding failure might make it difficult to debug those failures. Especially important for EWS, where engineers can't change the flag.
Jonathan Bedard
Comment 3 2019-11-21 09:35:04 PST
(In reply to Aakash Jain from comment #2) > Comment on attachment 383921 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=383921&action=review > > > Tools/Scripts/run-javascriptcore-tests:585 > > + print "$subTestName failed\n" if ($failureFlag && !$verbose); > > Shouldn't we print the failures irrespective of verbose flag. Hiding failure > might make it difficult to debug those failures. Especially important for > EWS, where engineers can't change the flag. If we're verbose, we would have printed the error line already on line 522, I was thinking that we wouldn't want to duplicate the printing. I don't feel super strongly about it either way, though.
Aakash Jain
Comment 4 2019-11-21 09:40:58 PST
Comment on attachment 383921 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=383921&action=review >>> Tools/Scripts/run-javascriptcore-tests:585 >>> + print "$subTestName failed\n" if ($failureFlag && !$verbose); >> >> Shouldn't we print the failures irrespective of verbose flag. Hiding failure might make it difficult to debug those failures. Especially important for EWS, where engineers can't change the flag. > > If we're verbose, we would have printed the error line already on line 522, I was thinking that we wouldn't want to duplicate the printing. > > I don't feel super strongly about it either way, though. That's ok either way. But why is this print inside if reportData?
Jonathan Bedard
Comment 5 2019-11-21 09:49:58 PST
Comment on attachment 383921 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=383921&action=review >>>> Tools/Scripts/run-javascriptcore-tests:585 >>>> + print "$subTestName failed\n" if ($failureFlag && !$verbose); >>> >>> Shouldn't we print the failures irrespective of verbose flag. Hiding failure might make it difficult to debug those failures. Especially important for EWS, where engineers can't change the flag. >> >> If we're verbose, we would have printed the error line already on line 522, I was thinking that we wouldn't want to duplicate the printing. >> >> I don't feel super strongly about it either way, though. > > That's ok either way. > > But why is this print inside if reportData? This is handling the case where we somehow duplicate a test name when parsing binary output. This is possible because we don't have great standards for how JSC binary tests are organized. That line of code is basically saying 'If we don't already have a result for this test, then'
WebKit Commit Bot
Comment 6 2019-11-22 10:26:02 PST
Comment on attachment 383921 [details] Patch Clearing flags on attachment: 383921 Committed r252781: <https://trac.webkit.org/changeset/252781>
WebKit Commit Bot
Comment 7 2019-11-22 10:26:03 PST
All reviewed patches have been landed. Closing bug.
Radar WebKit Bug Importer
Comment 8 2019-11-22 10:27:19 PST
Note You need to log in before you can comment on or make changes to this bug.