845388 - Switch Tinderboxprints from markup to json

Status: RESOLVED WONTFIX

(Release Engineering :: General, defect)

Description

[Ed Morley [:emorley]]

For datazilla, we changed the format of log file "TinderboxPrint:" prefixed lines to json rather than the usual markup that in some cases gets re-parsed, mangled and turned into more markup, and in others is inserted directly into the TBPL UI (!).

However for builds, unit tests & the old style graphs.m.o lines, we still use non-json formats.

We should convert the remaining uses into something non-markup-y, and ideally s/TinderboxPrint/SomethingElse/ (now that we don't use tinderbox).

Whilst the successor to TBPL will hopefully do away with the need for these prefixed log lines that get scraped by the TBPlv2 log parser (ie buildbot would pass test pass/fail counts etc to the new webservice directly), we'll still have to use them whilst we run TBPL and TBPLv2 in parallel - so I'd like them to be as yuck-free as possible, rather than have to dirty TBPLv2 with lots of edge cases supporting them.

Examples of the current mis-mash:

TinderboxPrint: <a title="trace_malloc_leaks" href='http://graphs.mozilla.org/graph.html#tests=[[28,63,8]]'>Lk:62.4KB</a>
TinderboxPrint: <a href='http://graphs.mozilla.org/graph.html#tests=[[207,63,24]]'>tp5n_pbytes_paint: 3.5GB</a>
TinderboxPrint:<a href=http://hg.mozilla.org/integration/mozilla-inbound/rev/7bdc94c723f3 title="Built from revision 7bdc94c723f3">rev:7bdc94c723f3</a>
TinderboxPrint: mozharness_revlink: http://hg.mozilla.org/build/mozharness/rev/87813aad3de4
TinderboxPrint: check<br/>37606/0
TinderboxPrint: crashtest-2<br/>754/0/5
08:45:52     INFO - TinderboxPrint: mochitest-chrome<br/>47441/0/151
08:52:15     INFO - TinderboxPrint: mochitest-a11y<br/>23908/0/1179
08:30:13     INFO - TinderboxPrint: marionette: 143/0/0

The newer Datazilla format:

TinderboxPrint: TalosResult: {"datazilla": {"tp5n": {"url": "https://datazilla.mozilla.org/talos/summary/Mozilla-Inbound/7bdc94c723f3?product=Firefox&branch_version=22.0a1"}}, "graphserver": {"tp5n_shutdown_paint": {"url": "http://graphs.mozilla.org/graph.html#tests=[[215,63,24]]", "result": "241.00"}, "tp5n_pbytes_paint": {"url": "http://graphs.mozilla.org/graph.html#tests=[[207,63,24]]", "result": "3.5GB"}, "tp5n_main_rss_paint": {"url": "http://graphs.mozilla.org/graph.html#tests=[[209,63,24]]", "result": "232.4MB"}, "tp5n_paint": {"url": "http://graphs.mozilla.org/graph.html#tests=[[206,63,24]]", "result": "168.73"}, "tp5n_responsiveness_paint": {"url": "http://graphs.mozilla.org/graph.html#tests=[[216,63,24]]", "result": "44.00"}}}

Comment 1

[Ed Morley [:emorley]]

I see this working as follows:
1) Decide on a new prefix
2) Decide on the json format (needs to support results, revision URLs & perhaps more)
3) (In a dependant bug) Add support for the new prefix/json format to TBPL, but make backwards compatible. Will need changes to:
https://hg.mozilla.org/webtools/tbpl/file/a3d6f7013d42/php/inc/TinderboxPrintFilter.php
https://hg.mozilla.org/webtools/tbpl/file/a3d6f7013d42/js/MachineResult.js#l53
https://hg.mozilla.org/webtools/tbpl/file/a3d6f7013d42/js/UserInterface.js#l1531
4) (In dependant bugs) Piecemeal switch all the buildbot/mozharness uses over to the new prefix/format.
5) Eventually depreciate TBPL support for the old format.

Note: It's my understanding that even given our wish to stop TBPlv2 having to directly deal with TinderboxPrints, we're still going to have cases where the test harness/build script wants to dump something to the log - and so having a unified format for buildbot to scrape/add to the object submitted to the TBPLv2 data store will still help.

Comment 3

[Ed Morley [:emorley]]

Any thoughts as to the new prefix?

Comment 6

[Ed Morley [:emorley]]

(In reply to Ed Morley [:edmorley UTC+0] from comment #3)
> Any thoughts as to the new prefix?

Something like "LogArtefact" (from treeherder's naming of the metadata), or catlee's suggestion on IRC - "AutomationInfo" perhaps.

Comment 7

[Chris AtLee [:catlee]]

Still needed?

Comment 8

[Ed Morley [:emorley]]

Yes

Comment 9

[Chris AtLee [:catlee]]

This isn't something RelEng is going to be working on. Feel free to re-open and move to a new component if needed though.