Try Server

An interesting use of the try server

I have a patch that’s ready to land.  I wanted to ensure that it compiles on all platforms.  I also wanted to ensure that it passes all tests, but I felt that running all the tests on one of the tier 1 platforms was enough.

There’s no way to specify this combination in a single try server push, but I realized I could do it with two separate pushes.  TryChooser told me that Linux64 was the least-loaded platform, so I did a try run with all the tests on that platform:

try: -b do -p linux64 -u all -t none

And then I did a try run that did builds (but no tests) on all platforms except Linux64:

try: -b do -p linux,macosx64,win32,android,android-armv6,android-noion,ics_armv7a_gecko,panda,otoro,unagi -u none -t none

Interesting.  I wonder if this is a combination that other people have considered.

5 replies on “An interesting use of the try server”

I’ve done this too, and mentally labeled it a “T run”, for the sideways T shape of the resulting tbpl output. I forget how I tried doing mine, other than whatever I did didn’t work quite right. Theoretically, something like try: -b do -p all -u all[x64] should work, where “x64” just happens to match 64-bit Linux builds and nothing else. (It matches a magic internal name that you probably have no way of seeing, that is.) See bug 802937 for what I’m using.

I just pushed to try testing it out. (Though come to think of it, that’s a useless push because it’ll only fire when the test fails. And it fails very very rarely. Doh! But that has nothing to do with T pushes.)

So, “T runs” are theoretically supported, but are undocumented, and may not actually work? Um, ok…


Or rather, there is an undocumented feature that happens to be useful for doing T pushes.

My excuse for not documenting it is mainly because to use it, you have to know the “prettyNames” for the test platforms, which is an internal implementation detail that I am a bad person for exposing, and that I am planning on changing sometime. Also, I originally thought that it would be useful for reducing try server load, but in practice it’s rarely applicable and syntactically obscure, so it hasn’t felt very useful to confuse people with yet another option when the current complexity already seems to be enough to keep most people using “-p all -u all”.

But your T pushes may tip the cost/benefit balance the other way. Ok, I’ll at least document some examples at . Maybe someday I’ll get around to writing a blog post.

I didn’t know that existed. I think we need to modify TryChooser to show a TBPL Test listing and let users select individual tests.

If you mean choosing tests individually per platform, the try syntax parser doesn’t currently support doing that. Or at least, not without severe contortions. The coupling between the set of available builds and TryChooser is pretty loose right now, which is hard to avoid when you’re using buildbot at scale, but it makes it very difficult to implement things like this (and especially to keep it up to date.)

But yes, it is possible and would be nice. I’m not sure we have much evidence for people’s willingness to use anything complicated for reducing their infra footprint, though.

Comments are closed.