Our fabulous intern Anamaria Stoica has been working hard the past few months helping to pull data from buildbot’s scheduler DB that allows us to learn all sorts of new information about how the release infrastructure is being used, and how it could be optimized. Among other things, she’s generated an end-to-end report so we can see at a glance how long the complete build cycle for any push to mozilla-central took.  Now, on top of that, she’s added a way to see who is using the awesome new TryChooser syntax.

In the coming weeks I’ll be emailing folks who are using try but not the TryChooser syntax and encouraging them to give it a shot. In my stock email letter I will say something along the lines of:

When you use the TryChooser syntax to make requests for only what you need, you allow precious CPU cycle time to be used elsewhere by those who need it.

This is helpful for two reasons:

1. Those testing fixes to blockers of the next beta/rc/release can get try results quickly and get their code landed on trunk
2. Overall wait times for try results are reduced

What’s interesting in looking at the reports though is that more of the pushes to try that use TryChooser are green. Here’s a snapshot of those who are using TryChooser:

The number of build requests is an aggregate of all the builders triggered so all build types, platforms, test and talos builders run on that push.

Now for comparison, here’s a snapshot of folks not using the TryChooser:

I have no way of knowing from this snapshot which of those pushes were intentionally not using the TryChooser and perhaps trying to get all 176 possible builds. Some of them may be using custom mozconfigs as a way to kill off unwanted builds (p.s. you get burning with that).

If you haven’t tried it yet, please give TryChooser a go and see if getting a smaller set of builds (ie: what you need, not just the default) and perhaps getting more green on you try pushes gives you a boost.

Last week bug 473184 saw some progress when we landed the try_parser which allows devs to put in their hg commit comments what try builds they would like on a particular push. This is a first step towards a two-part goal: 1) giving devs more self-serve tools for try and 2) lowering try wait-times.

Now you can try what you want instead of just pushing and getting the default set (currently default is all opt & debug builds, all unittests, no talos).  You will get less emails and only the results you’re looking for and everyone wins when you only ask for what you need since it will make more machines available for other builds.

To use this fabulous new TryChooser in your commit message (soon to be available in a committed config file as well) you do the following:

• You’ve got your patch ready to try
• Set the commit comment to what you would like to run on try
• In this case, let’s say you want a linux opt build, no mobile, no unittests, and only talos tp4 results

hg commit -m “Patch to fix a pixel placement try: –build o –p linux –m none –u none –t tp4”

• Push to try
• What happens? ‘Linux tryserver build’ builder is created and runs your opt linux build. If the build completes successfully then the talos tests are triggered and once the test-master gets the notice of the change it will read the hg commit comments and only kick off the one builder for tp4 ‘Rev3 Fedora 12 tryserver talos tp4’ 
• You get a total of 3 emails and have used very little compute time – you rock!

please go to http://wiki.mozilla.org/Build:TryChooser for complete info and options as well as some answers to questions you make have and take the TryChooser out for a spin.

This week is all about getting custom selection for tryserver submissions (bug 473184) ready for public consumption. The plan is to have a custom scheduler that calls a function which parses a commit comment (and later, the option of an .info file instead) and then only schedules the builders which have been requested. This will be awesome for our build machine resources since it will mean that if you don’t want a particular platform/test/talos suite it will never even get triggered.

In today’s work on the parser I wrote python unittests for the first time. I remember doing some unittests in school but that was way back when we used Java. The python unittest module is really awesome and easy to get up and running. Once I had my tests passing I then ran the coverage tool on both the test suite and the parser to see how I did in covering all my bases:

This tool is Frickin’ Awesome! I can see at a glance that I need another test to see what happens if someone wants a subset of mobile build platforms.

Tomorrow I’ll be getting my coverage even higher and then starting to stage this scheduler and see how it handles our large amount of possible builders to choose from. Keep your ears open – selecting your try build configuration is right around the corner.