721152 - Display results for a push when rev=X is in the query string, even if that rev isn't in a pushlog or the pushlog fails to load

Status: RESOLVED FIXED

(Tree Management Graveyard :: TBPL, defect)

Description

[[e-mail] (:bhearsum)]

14:40 < philor> someday we ought to teach tbpl to display results for rev=, even if it can't load the pushlog, so people who at least have the first email can still 
                load their results

Comment 1

[Phil Ringnalda (:philor)]

The fuller form of that being that the tryserver repo frequently gets messed up, and also frequently just gets so many heads that it gets horribly slow, and releng+IT would like to be able to just blow it away and reclone from m-c, but since that removes the pushlog, tbpl winds up unwilling to display results for the pushes from before the reset, so anyone who hasn't gotten or looked at their results yet loses. We should be able to special-case rev=deadbeef1234, just fake up a pushlog for (unknown) (unknown), and display the results, so that the people who kept the first email from try with the tbpl.m.o/tree=try&rev=deadbeef1234 link don't have to repush.

Comment 2

[Ed Morley [:emorley]]

Attachment: Patch v1

This patch:
* Adds a timeout to the json-pushes load, where there was not one before - making it clearer that it's a problem with hg.m.o not TBPL (hopefully reducing the number of times we have to explain on IRC). The longest json-pushes load I could find was on a release branch merge day push, which was 4s, which multiplied by a somewhat arbitrary 5 to allow for slow connections, gives 20s (happy to adjust).
* Adds a fall-back for the single revision mode case (ie: &rev=foo specified) when the json-pushes load failed (either due to timeout, or revision not found), which fakes the date/pusher name/patch list/commit messages etc - but means we at least populate job results in the UI.
* Makes the timeout shorter for the try + single revision case, since the fall-back provides 95% of the functionality & the longer timeout only really serves to irritate. The longest try single-changset json-pushes call I could find was 1.5s, which multiplied by the arbitrary 5, gives ~8s (again, happy to adjust).

Hopefully this will make the try hg.m.o issues much more tolerable - if json-pushes is timing out, people can view their job results as long as they use &rev= in the query string, plus when the try repo is reset, the old links will still work (the usual 30 day TBPL data cleanup excepted).

Comment 3

[Ed Morley [:emorley]]

Attachment: screenshot

Comment 4

[Ed Morley [:emorley]]

Meant to say - I picked |Date(0)| rather than |Date()| for the fake date, since using today's date doesn't make it clear in the UI that it's an incorrect value.

Comment 5

[Arpad Borsos [:Swatinem]]

(In reply to Ed Morley [:edmorley UTC+0] from comment #4)
> Meant to say - I picked |Date(0)| rather than |Date()| for the fake date,
> since using today's date doesn't make it clear in the UI that it's an
> incorrect value.

That looks really funny with the timezone adjustment we are doing, haha.
But its feedback+ from me.

Comment 6

[Phil Ringnalda (:philor)]

Comment on attachment 8360378 [details] [diff] [review]
Patch v1

Nice!

Comment 7

[Ed Morley [:emorley]]

Ty :-)

https://hg.mozilla.org/webtools/tbpl/rev/4e3ed9dc8c66

Comment 8

[Ed Morley [:emorley]]

In production :-)

Comment 9

[Steve Fink [:sfink] [:s:]]

I object! This is wrong! tbpl stands for "tinderbox PUSH LOG". What part of "push log" don't you understand?

/me goes back to his cached tinderbox waterfall page, searching in vain for his build...