I think that it is sufficient to watch for '^\[ FAILED \]' in logs. Ideally, this would also walk backwards 4-6 lines until it finds ':\d+: failure$'.
Links to example logs please!
Created attachment 8838309 [details] [review] [treeherder] martinthomson:bug1340329 > mozilla:master
Comment on attachment 8838309 [details] [review] [treeherder] martinthomson:bug1340329 > mozilla:master Soo fast! https://public-artifacts.taskcluster.net/rJ9eZDqIQoq46BNVIuPi4Q/0/public/logs/live_backing.log
Attachment #8838309 - Flags: review?(emorley)
Comment on attachment 8838309 [details] [review] [treeherder] martinthomson:bug1340329 > mozilla:master So in some future world I'd hoped we could significantly reduce the number of cases the log parser has to support, and push that work down to the individual test runners/harnesses etc (for example match only against mozharness style log line error level prefixes, and let mozharness or a taskcluster wrapper decide what counts as an error line). However given the mixture of job types we have (plus the current lack of standard format for denoting an error line, given that mozharnesses prefixes aren't even used by much of taskcluster), I think that future state is quite far away, so we'll sadly have to accept further regex additions for now. Thank you for the PR :-)
Attachment #8838309 - Flags: review?(emorley) → review+
Commit pushed to master at https://github.com/mozilla/treeherder https://github.com/mozilla/treeherder/commit/97a93cd11b7ae9076b48a5e8e87a7fcd80ceea0e Bug 1340329 - Recognize gtest failure lines as errors
This will auto-deploy to Treeherder stage in a few minutes, and will be deployed to Treeherder production at some point soon (typically 1-2 times per week). It's worth noting that the log parser only runs once, so error summaries generated prior to this landing won't be updated.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.