1023871 - Treeherder job metadata panel contains malformed markup for some TinderboxPrint stats

Status: RESOLVED FIXED

(Tree Management :: Treeherder, defect, P2)

Description

[Ed Morley [:emorley]]

(I'll move this to the new treeherder component, once created)

Looking at:
http://treeherder-dev.allizom.org/ui/#/jobs?repo=mozilla-central&revision=75377bac231e

And clicking the Windows XP pgo build ("B"), the panel in the bottom of the treeherder UI that shows the job stats, lists:

{
    Machine name: b-2008-ix-0162
    Build: x86 windowsxp win
    Duration: 201 minutes
    Job Name: Build
    Machine : x86 win
    Start time: 6/11/14 3:30 AM

    linker max vsize 3006025728
    <a title="libxul_link" href='http://graphs.mozilla.org/graph.html#tests=[[205,1,8]]'>libxul_link:3006025728</a>
    check 4483/0
}

... where the first "3006025728" is linked to:
http://treeherder-dev.allizom.org/ui/3006025728
...which 404s.

And this line is escaped and thus not clickable:
<a title="libxul_link" href='http://graphs.mozilla.org/graph.html#tests=[[205,1,8]]'>libxul_link:3006025728</a>

Comment 2

[Cameron Dawson [:camd]]

The revision seems to have been purged from dev.  I'll try to find another example on prod.

Comment 3

[Cameron Dawson [:camd]]

Here's a recent-ish one: https://treeherder.mozilla.org/ui/#/jobs?repo=mozilla-inbound&revision=b86f48fe5da8

That part of the link is truncated for me.  But it's not a live link, that's true.  I'm not clear if it should be.  That seems like untrusted html to me.  Or were we confirming that we would trust anything within the mozilla.org domain?

Mauro- What do you think the best way to handle that would be?

Comment 4

[Ed Morley [:emorley]]

Inserting markup into the logs is bad, and is something that I would like to see go away eventually (bug 845388 will handle this). In the meantime, it would be great if we could extract the URLs in a safe manner and at least preserve a clickable link whilst the transition to json takes place.

Comment 5

[Ed Morley [:emorley]]

The example from comment 0 is Windows PGO job. The raw TinderboxPrint line is:
TinderboxPrint: <a title="libxul_link" href='http://graphs.mozilla.org/graph.html#tests=[[205,63,8]]'>libxul_link:2918047744</a>

This comes from:
http://mxr.mozilla.org/build-central/source/tools/buildfarm/utils/graph_server_post.py#31
30                 tboxPrint =  'TinderboxPrint: ' + \
31                     '<a title="%s" href=\'http://%s/%s\'>%s:%s</a>\n' % \
32                     (testlongname, self.server, line.split("\t")[3],
33                     testname, prettyval)
34                 print tboxPrint

That said, I can see a few other places where we "TinderboxPrint: <a .* href=foo .*>bar</a>", so it would be good if we could just safely extract from them for now, and bug 845388 will clean this up longer term.

Comment 6

[Mauro Doglio [:mdoglio]]

I refactored a bit the way we parse the tinderbox printlines. The number of different cases to take in account was growing too much, so I decided to use regular expressions to try to recognize known patterns representing links. If no pattern is recognized, the resulting artifact will have a 'html' content type. That means that the ui will sanitize its content and show it as html. Downstream application will have to do their own parsing in order to extract structured info out of these artifacts.

Comment 7

[Mauro Doglio [:mdoglio]]

Attachment: Github PR #181 on treeherder-service

Comment 8

[Ed Morley [:emorley]]

Comment on attachment 8463512 [details] [review]
Github PR #181  on treeherder-service

Looks like this was merged already:
https://github.com/mozilla/treeherder-service/commit/b1e1ad161f4809bfc1f75578e125af618ab7b40f