608698 - Allow linking to TBPL commits

Status: RESOLVED DUPLICATE of bug 619672

(Tree Management Graveyard :: TBPL, defect)

Description

[Paul Biggar]

It isn't possible to link to TBPL commits, and they change so quickly that it can take minutes to go hunting for them. Can we make it so that http://tbpl.mozilla.org/?tree=TREENAME#cCOMMITID brings you to the TBPL commit log for COMMITID?

It would be great to get a link to this as part of tryserver emails too.

Comment 1

[Phil Ringnalda (:philor)]

http://tbpl.mozilla.org/?tree=MozillaTry#push-6e99f7c6b6b1 already exists, but it doesn't really work, since the browser tries to scroll to it onload, and at onload only the outer shell of tbpl has loaded, not the content. You can sort of make it work, by hitting enter in the addressbar after the content has loaded, but that doesn't maintain your scroll position when new pushes are loaded. Dunno whether we could sniff location.hash and reset it every time content loads to persuade the browser to stay scrolled to your push or not.

http://tbpl.mozilla.org/?tree=MozillaTry&rev=6e99f7c6b6b1 also already exists, but since in 12 hours that will load empty claiming "there are no pushes to show" and require you to know that means you have to click the down arrow to load older pushes, it's not an entirely perfect URL to use in tryserver email (and automatically loading older and older pushlogs until we find the push is sort of worrisome, since both a bogus URI or a correct one when something's busted in pushlog so your rev doesn't appear in the current chunk would result in loading every single bit of pushlog back to the dawn of time in 12 hour chunnks).

Comment 2

[Paul Biggar]

(In reply to comment #1)

I hadn't realized there were both these features. If we can get this to work, it would be great to include these in the TryServer emails, and to link to them from places like hg.m.o.

> http://tbpl.mozilla.org/?tree=MozillaTry#push-6e99f7c6b6b1 already exists, but
> it doesn't really work, since the browser tries to scroll to it onload, and at
> onload only the outer shell of tbpl has loaded, not the content. You can sort
> of make it work, by hitting enter in the addressbar after the content has
> loaded, but that doesn't maintain your scroll position when new pushes are
> loaded. Dunno whether we could sniff location.hash and reset it every time
> content loads to persuade the browser to stay scrolled to your push or not.

I guess the right behaviour is:
 - scroll to it after the content loads the first time
 - if the page is not scrolled to the very top, scroll down by the amount of new content loaded. I'm not sure if this part is possible.

 
> http://tbpl.mozilla.org/?tree=MozillaTry&rev=6e99f7c6b6b1 also already exists,
> but since in 12 hours that will load empty claiming "there are no pushes to
> show" and require you to know that means you have to click the down arrow to
> load older pushes, it's not an entirely perfect URL to use in tryserver email
> (and automatically loading older and older pushlogs until we find the push is
> sort of worrisome, since both a bogus URI or a correct one when something's
> busted in pushlog so your rev doesn't appear in the current chunk would result
> in loading every single bit of pushlog back to the dawn of time in 12 hour
> chunnks).

Since &rev= is serverside, can we load only the 12 hour window around that commit? In the event that that 12 hour window was not recent, we wouldn't keep loading new content.

Comment 3

[Phil Ringnalda (:philor)]

In a happy future bug 553549 world, when &rev= actually is serverside, then it will be perfect, and will always just load/reload that rev, and will be the right thing to include in tryserver email.

In the present world, nothing is happening on the server, because no server we can use exists which knows the results of builds based on a rev - tinderbox is entirely time-based (and ancient unmaintainable unchangeable crud), and pushlog has no idea when things actually were built, and buildbot, the only thing that does know what happened to builds for a particular rev, is so fragile and overloaded that we are not allowed to use it.

The current impl of &rev= just tells the JS running in your browser to load exactly the same XHRs from pushlog and tinderbox that it was going to load anyway, and throw away the results that don't match that rev. A slightly smarter one, which starts by querying pushlog for the rev, to find out when it was pushed, then does a potentially huge query of tinderbox for everything from that time to the present, throws away everything but your rev, and then uses builds-running.js to tell it whether there's anything still pending or running to know whether it needs to keep reloading the last 12 hours of tinderbox, would be possible, it would just be a lot more intrusive in the tbpl code than the present impl is.

Comment 4

[Paul Biggar]

OK, looks like there's a lot to do before we get here. Thanks.

Comment 5

[Markus Stange [:mstange]]

(In reply to comment #2)
> Since &rev= is serverside, can we load only the 12 hour window around that
> commit?

That's exactly what we do now (since bug 619673). 12 hours might not always be enough but it'll have to suffice until we switch to the push-based server-side database.
So http://tbpl.mozilla.org/?tree=MozillaTry&rev=d6246f7ae8b2 works now.

Comment 6

[Paul Biggar]

Looks like tihs is done then.