741775 - TBPL Try runs don't show any status if the try is from a mercurial branch

Status: RESOLVED FIXED

(Tree Management Graveyard :: TBPL, defect)

Description

[Randell Jesup [:jesup] (needinfo me)]

When pushing to try from a mercurial branch, the build and tests run, but the UI for TBPL doesn't show any results.  Gray 'B's appear until builds finish, then they go away.  No test runs show up, but the self-serv API shows they ran.

See this build for example:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-819d2266ba63/
and
https://build.mozilla.org/buildapi/self-serve/try/rev/819d2266ba63

Comment 1

[Chris AtLee [:catlee]]

The builds also complete and have logs uploaded to ftp, and details of the builds/tests are exported in the build json.

Comment 2

[Phil Ringnalda (:philor)]

tbpl works by having your browser parse a pushlog, determine which cset in each push would be the one which jobs would report having run on, and query the server for results for that cset.

Because bug 602148 didn't know about http://hg.mozilla.org/build/buildbotcustom/annotate/5eb1b8c95cb9//misc.py#l744 it thought that the cset on which jobs would report having run would always be the tip-most one on the default branch, rather than being the tip-most one on the default branch on non-try trees, and the tip-most one on try.

Comment 3

[Matt Brubeck (:mbrubeck)]

Attachment: patch

This basically takes the fix from 602148 and disables it on Try.  Untested -- is there a real-world push that currently shows this problem for testing?

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

Check the alder repo; we push a lot of branch updates currently.

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

Or rather, have ekr or ehugg or crypt, who work on branches on alder, push a try build.  (See #media)

Comment 6

[Matt Brubeck (:mbrubeck)]

Attachment: patch v2

Nevermind, checked Try and found 6f3675462952 showing this problem currently.  This patch fixes the display for that push.

Comment 7

[Phil Ringnalda (:philor)]

In theory, the test that you aren't breaking the non-try case would be https://tbpl.mozilla.org/?tree=Mozilla-Beta&rev=6ebda0cacad3

In fact, bug 653041 broke building on anything other than the tipmost cset in a push more than a year ago, since the poller only sees the tipmost cset.

Not sure whether that means we should file on the releng regression, or just decide that's the new world order, and drop all the defaultTip stuff. catlee?

Comment 8

[Phil Ringnalda (:philor)]

Comment on attachment 638489 [details] [diff] [review]
patch v2

Meh, no actual answer there either. Let's go with this for now, it doesn't really cost anything to pointlessly poll defaultTip in the cases where neither that nor tip got built, and we can alway yank out the whole defaultTip thing when someone stumbles on it after it's been so long that nobody can remember non-default pushes on non-Try ever building anything at all.

Comment 9

[Matt Brubeck (:mbrubeck)]

https://hg.mozilla.org/users/mstange_themasta.com/tinderboxpushlog/rev/a7b02d5b8785