Mozilla Productivity Tip: Managing try pushes



All timestamps are based on your local time of:

Posted by: stak
Tags: mozilla
Posted on: 2018-10-18 08:08:32

I tend to do a lot of try pushes for testing changes to Gecko and other stuff, and by using one of TreeHerder's (apparently) lesser-known features, managing these pushes to see their results is really easy. If you have trouble managing your try pushes, consider this:

Open a tab with an author filter for yourself. You can do this by clicking on your email address on any of your try pushes (see highlighted area in screenshot below). Keep this tab open, forever. By default it shows you the last 10 try pushes you did, and if you leave it open, it will auto-update to show newer try pushes that you do.

With this tab open, you can easily keep an eye on your try pushes. Once the oldest try pushes are "done" (all jobs completed, you've checked the result, and you don't care about it anymore), you can quickly and easily drop it off the bottom by clicking on the "Set as bottom of range" menu item on the oldest push that you do want to keep. (Again, see screenshot below).

TreeHerder with the author and "Bottom of range" highlighted.
TreeHerder with the author and "Bottom of range" highlighted.



This effectively turns this tab into a rotating buffer of the try pushes you care about, with the oldest ones moving down and eventually getting removed via use of "Set as bottom of range" and the newer ones automatically appearing on top.

Note: clicking on the "Set as bottom of range" link will also reload the TreeHerder page, which means errors that might otherwise accumulate (due to e.g. sleeping your laptop for a time, or a new TreeHerder version getting deployed) get cleared away, so it's even self-healing!

Bonus tip: Before you clear away old try pushes that you don't care about, quickly go through them to make sure they are all marked "Complete". If they still have jobs running that you don't care about, do everybody a favor and hit the push cancellation button (the "X" icon next to "View Tests") before resetting the bottom of range, as that will ensure we don't waste machine time running jobs nobody cares about.

Extra bonus tip: Since using this technique this makes all those "Thank you for your try submission" Taskcluster emails redundant, set up an email filter to reroute those emails to the /dev/null of your choice. Less email results in a happier you!

Final bonus tip: If you need to copy a link to a specific try push (for pasting in a bug, for example), right-click on the timestamp for that try push (to the left of your email address), and copy the URL for that link. That link is for that specific push, and can be shared to get the desired results.

And there you have it, folks, a nice simple way to manage all your try pushes on a single page and not get overwhelmed.

Posted by njn at 2018-10-18 19:31:21
Not bad! The only downside I can see is that it assumes you deal with try pushes in a FIFO manner, which isn't always the case for me. So I'll stick with one tab per try push for now :)
[ Reply to this ]
Posted by stak at 2018-10-18 19:43:44
They generally finish in a FIFO manner, unless you have significantly different jobs scheduled per push. But yeah, that happens to me sometimes, and I've wanted to write a patch to TH that collapses/hides a specific push from the view. But I haven't gotten around to it yet :/
[ Reply to this ]
Posted by botond at 2018-10-19 20:17:03
I like having one tab per Try push open, so that I can see if any of them have failures at a glance by looking at the [number] in the tab title.
[ Reply to this ]
Posted by sfink at 2018-10-22 11:08:13
I keep my try author page open all the time too. I'm also a tab hoarder, so I usually get back to it via '% treeh try' in the URL bar -- which unfortunately doesn't work very well anymore, since the location bar now searches only the current container, and I am often in a different container (usually the bugzilla container, which you really ought to have if you have secure bug access.)

I have long wanted a way to collapse individual pushes in that few too, since my pushes are frequently non-FIFO. I'll do a rebase-and-retry on project 1, then switch to project 2 where I have a long stack of patches and want to see how much of it I could land. So I do half a dozen try pushes, just before each of the "scary" changesets.
[ Reply to this ]

[ Add a new comment ]

 
 
(c) Kartikaya Gupta, 2004-2018. User comments owned by their respective posters. All rights reserved.
You are accessing this website via IPv4. Consider upgrading to IPv6!