588686 - Move TinderboxPrint of "rev:[short_changesetid]" up higher in Tinderbox logs so TBPL can catch it

Status: RESOLVED WORKSFORME

(Release Engineering :: General, enhancement, P5)

Description

[Daniel Holbert [:dholbert]]

A few hours ago, a TryServer log of mine failed due to timeout during HG clone, but it never showed up on TBPL, despite having TinderboxPrint'ed its revision as follows (copying & pasting from Tinderbox):
> L!
> s: try-linux-slave08
> s: d5c196ef5ed6594adaa2cda1de631e6892749dd8
(I'd initially thought this was enough to get it to show up on tbpl)

The log is:
http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTry/1282178040.1282180111.11311.gz

From comparing its Tinderbox output vs. that of other build-failures that *did* appear on TBPL, I think the key thing it's missing is an additional line, which is:
 "rev: [short_changesetid]"
which (I'm guessing) is what tbpl looks for.

E.g. here's the Tinderbox output of a different failed build that *did* show up on tbpl:
> L!
> s: try-linux64-slave05
> s: 26089df3e9387fcf0305d30255a18ddd4fa8d14b
> rev:26089df3e938
http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTry/1282179454.1282181198.16708.gz

If it would be at all possible to print that "rev:" line earlier so that tbpl can pick it up, that would be amazing...

We have all the information that we need to construct it (it's just the first 12 characters of the long-form changeset ID, and we can construct the URL for linkifaction by just concatenating [repo URL]+/rev/+[short_changesetid]

Comment 1

[Daniel Holbert [:dholbert]]

BTW, the reason the current behavior is particularly frustrating is that even under normal circumstances, build-boxes frequently don't show up on TBPL right away.  My current cycle for getting my tryserver results is:
* Look at TBPL: Is there a gray letter for the build(s) you're interested in?
 (a) If yes, wait for it to turn green or red, and then watch for test-results.
 (b) If no, wait... it'll be there.

Most of the time this works, but when we have an issue during |hg clone| that prevents tbpl from picking up the build, that leaves me stuck in part "(b)" above. (until I break down and look at long-form-tinderbox)

Comment 2

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

(In reply to comment #2)
> A few hours ago, a TryServer log of mine failed due to timeout during HG clone,

This hg timeout problem is being tracked in bug#588711.

Comment 3

[Daniel Holbert [:dholbert]]

FWIW, I hit another build failure today that triggered this burning-builds-not-showing-up-on-TBPL-even-though-we-know-the-long-form-changset-ID issue: bug 596709

Comment 4

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

dholbert: 

Since this bug was filed in August, tbpl has been migrating from scraping tinderbox waterfall to accessing data directly from buildbot db. I'd expect this to be fixed by the migration. Also, logs are now posted with build on ftp.m.o. Are you still seeing this problem?


(this bug filed months ago - sorry for not replying sooner)

Comment 5

[Daniel Holbert [:dholbert]]

I'm not sure if this is fixed, but I haven't run up against the problem for quite a while.

(of course, it's only a problem when a tryserver build gets interrupted/killed very early in the build process)

I'd be happy to have this resolved, though I'm not sure what the correct resolution would be. (WORKSFORME?)

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to comment #5)
> (of course, it's only a problem when a tryserver build gets interrupted/killed
> very early in the build process)

I meant to add the following there:
...and I haven't (knowingly) had that happen for quite some time, happily :) -- so it's theoretically possible that this is still an issue & I just haven't hit the right set of conditions to trigger it for quite a while.

Comment 7

[Markus Stange [:mstange]]

(In reply to comment #4)
> Since this bug was filed in August, tbpl has been migrating from scraping
> tinderbox waterfall to accessing data directly from buildbot db.

Unfortunately we're not quite there yet. We use information about pending and running builds from buildbot, but the information about finished builds still comes from Tinderbox. The switch is not far away though!

Dholbert, I think in the meantime there have been changes to TBPL's detection of "rev:" in the scrape, and maybe we're not affected by the order anymore. I'll look into it.

Comment 8

[Markus Stange [:mstange]]

Actually, I don't even understand how this bug could happen at all. We're not looking for "rev:", we're exploiting the fact that the revision is linked to the changeset page on hg.mozilla.org, and taking our revision from the link address.

http://hg.mozilla.org/users/mstange_themasta.com/tinderboxpushlog/rev/e9277b990cdd made our algorithm more robust, so maybe it fixed it anyway.

Let's reopen if the bug occurs again.