Closed Bug 565307 Opened 10 years ago Closed 8 years ago

[TopFails] tracking bug for (Mochitests) log parsing errors

Categories

(Testing :: General, defect)

x86
macOS
defect
Not set

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: armenzg, Assigned: k0scist)

References

(Blocks 1 open bug)

Details

When I visit this page I get the following:
http://brasstacks.mozilla.com/topfails/test/Firefox?name=chrome://mochikit/content/chrome/dom/tests/mochitest/chrome/test_focus.xul
++++++++
Page not found (404)
Request Method: 	GET
Request URL: 	http://brasstacks.mozilla.com/topfails/test/Firefox?name=chrome://mochikit/content/chrome/dom/tests/mochitest/chrome/test_focus.xul

No TestFailure matches the given query.

You're seeing this error because you have DEBUG = True in your Django settings file. Change that to False, and Django will display a standard 404 page.
++++++++

There is a test failure in the following log and I expected it to show up:
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1273648598.1273649788.12380.gz

This is the bug tracking the failure since Nov. 2009:
https://bugzilla.mozilla.org/show_bug.cgi?id=527099
These results are not yet picked up by the cron job. Currently, the cron job runs twice a day. I will make sure that the cron job changes to once every 3 hours before EOD today
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
Assignee: nobody → murali.nandigama
Murali, this is not WFM.  You absolutely cannot show the Django debug output as an error message.  You'll still need a real error message here, even if you up the frequency of the cron job.  Please morph this bug to add such an error message.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
I think the original purpose of this bug is being side-tracked.

When I try to see the test failures for:
chrome://mochikit/content/chrome/dom/tests/mochitest/chrome/test_focus.xul

Should I get to see it by visiting http://brasstacks.mozilla.com/topfails/test/Firefox?name=chrome://mochikit/content/chrome/dom/tests/mochitest/chrome/test_focus.xul ?
Summary: [TopFails] chrome://mochikit/content/chrome/dom/tests/mochitest/chrome/test_focus.xul does not show up → topfails cronjob frequency to be changed to perform frequent data scraping from tinderbox
Assignee: murali.nandigama → jgriffin
Looking at the history in bug 527099, it seems that this failure should have shown up in the topfails db even though the scraper runs only twice per day, since it also occurred on, e.g., May 9.  So this may be a problem with the log scraper, instead of just the fact that the data can be up to 12 hours old.

I'm assigning this to jhammel since he owns this component going forward.
Assignee: jgriffin → jhammel
Summary: topfails cronjob frequency to be changed to perform frequent data scraping from tinderbox → [TopFails] chrome://mochikit/content/chrome/dom/tests/mochitest/chrome/test_focus.xul does not show up
The DEBUG issue is fixed now;  the body of the bug, not so much
Jeff .. I presume that you are working on the logic to parse the log file pertaining to this issue.

Cheers
Murali
(In reply to comment #7)
> Jeff .. I presume that you are working on the logic to parse the log file
> pertaining to this issue.
> 
> Cheers
> Murali

Not right at the moment.  Why?
So going through this bug, a number of issues are being conflated.  I'm going to try to sort them out:

 - this bug is being used as a tracking bug for several different cases where topfails doesn't find the error in the log.  Is this what we want to do?  if yes, then we should change the title to something more appropriate.  If not, then we should file separate bugs for each case where it fails

 - for each case when it fails, a the log that contains the failure should be uploaded and verbosely which error topfails doesn't find should be described.  Without this debugging information, it will be impossible to reproduce and fix. (Not meant as an excuse, but fixing topfails is not on my high-priority tasks for this quarter, so I don't have time to hunt for bugs in logs and debug + fix topfails.)

Those I think are the two action items.
I am not using TopFails anymore so there is nothing from me to add. It is up to the rest to (In reply to comment #4)
> I think the original purpose of this bug is being side-tracked.
> 
> When I try to see the test failures for:
> chrome://mochikit/content/chrome/dom/tests/mochitest/chrome/test_focus.xul
> 
> Should I get to see it by visiting
> http://brasstacks.mozilla.com/topfails/test/Firefox?name=chrome://mochikit/content/chrome/dom/tests/mochitest/chrome/test_focus.xul
> ?

The page works for me showing me the test failure occurred on "Rev3 WINNT 6.1 mozilla-central opt test mochitest-other".

I thinks this is WORKSFORME or RESOLVED FIXED; isn't?
(In reply to comment #10)
> I am not using TopFails anymore so there is nothing from me to add. It is up to
> the rest to (In reply to comment #4)
> > I think the original purpose of this bug is being side-tracked.
> > 
> > When I try to see the test failures for:
> > chrome://mochikit/content/chrome/dom/tests/mochitest/chrome/test_focus.xul
> > 
> > Should I get to see it by visiting
> > http://brasstacks.mozilla.com/topfails/test/Firefox?name=chrome://mochikit/content/chrome/dom/tests/mochitest/chrome/test_focus.xul
> > ?
> 
> The page works for me showing me the test failure occurred on "Rev3 WINNT 6.1
> mozilla-central opt test mochitest-other".
> 
> I thinks this is WORKSFORME or RESOLVED FIXED; isn't?

Yeah, that exists now.  But see comment 9.
(In reply to comment #11)
> (In reply to comment #10)
> > I thinks this is WORKSFORME or RESOLVED FIXED; isn't?
> 
> Yeah, that exists now.  But see comment 9.

I will let others answer as I am not anymore a stake-holder for TopFails as I am not anymore a user of it.
(In reply to comment #9)

W.r.t. the dependent bugs I added, I think they explicitly contain the errors and/or the link to the logs.

W.r.t TopFails missing some test failures, I would hope there could be a way for TopFails to compare its parsing results with the (failed) test summary in the log, then "warn" if the two numbers differ in an unexpected way.

NB: Same comments apply to bug 564234.
this dependencies of these bug have been used to denote additional log parsing issues.  Changing the bug title to correctly note bug intention.
Summary: [TopFails] chrome://mochikit/content/chrome/dom/tests/mochitest/chrome/test_focus.xul does not show up → [TopFails] tracking bug for log parsing errors
Depends on: 564234
Summary: [TopFails] tracking bug for log parsing errors → [TopFails] tracking bug for (Mochitests) log parsing errors
Depends on: 606208
Blocks: 606208
No longer depends on: 606208
topfails has been supplanted by the Orage Factor: 

- https://wiki.mozilla.org/Auto-tools/Projects/WarOnOrange
- http://brasstacks.mozilla.com/orangefactor/

This uses a greatly improved log parser:

- https://wiki.mozilla.org/Auto-tools/Projects/Autolog
- http://hg.mozilla.org/automation/logparser/

We've turned off the topfails server.  If there are any addition needs for Orange Factor, please file them in the Testing::Orange Factor component.
Status: REOPENED → RESOLVED
Closed: 10 years ago8 years ago
Resolution: --- → WONTFIX
Component: Infrastructure → General
You need to log in before you can comment on or make changes to this bug.