656908 - Allow machineResult.getTestResults() to be asynchronous

Status: RESOLVED FIXED

(Tree Management Graveyard :: TBPL, defect)

Description

[Markus Stange [:mstange]]

Attachment: v1

With the buildbot DB backend, we don't get the "TinderboxPrint:" scrape supplied with the run data. Instead we need to generate it by parsing the logs, and I don't think we should parse all logs unconditionally, so we'll only do it on request, and that means that machineResult.getTestResults() needs to be asynchronous (since it needs the scrape).

TinderboxJSONUser won't go the async path, but BuildbotDBUser (coming in a different bug) will.

Comment 1

[Mark Banner (:standard8)]

If we're all having to parse the logs for the same data, shouldn't we really be having buildbot or something generate separate logs (or some sort of file) with the extra information?

Comment 2

[Arpad Borsos [:Swatinem]]

Comment on attachment 532215 [details] [diff] [review]
v1

Review of attachment 532215 [details] [diff] [review]:
-----------------------------------------------------------------

Well I do understand what you are doing here, but I don’t think its very clear to mix the callback and the non-callback version. Rather go the callback-way only, even if you have the scrape already. To avoid races, we would want to first insert the element into the dom, then call getresults that will write there hopefully immediately when we already have a cached _scrape.

I will r+ this for now but hopefully some followup patch will clean that up.

Comment 3

[Markus Stange [:mstange]]

(In reply to comment #1)
> If we're all having to parse the logs for the same data, shouldn't we really
> be having buildbot or something generate separate logs (or some sort of
> file) with the extra information?

When "or something" could also be "the TBPL server", then that's what we're doing, isn't it?

Comment 4

[Markus Stange [:mstange]]

http://hg.mozilla.org/users/mstange_themasta.com/tinderboxpushlog/rev/bd27a5d13a5d