Try What You Want

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.

No really, it *is* easy to test your Python code

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.

Disposable Project Branches – aka Twigs

Hey Firefox Developers – Want a place that’s kind of like Tryserver but all yours for a short period of time?  Release Engineering now has 3 ‘disposable’ branches set up in our build automation that you can use for testing a mozilla-central clone or a clone of your own m-c-based repo.  I call them Twigs because they are for temporary, small projects.

The Twigs (maple, cedar, and birch) each have their own tinderbox pages, run the full suite of unittests, and give you talos results by default.  Like Tryserver, they also allow you to override the mozconfig with a custom mozconfig so that you could kill off platforms you are not interested in results for.  Doing so will give you a cleaner tree and will allow our build and test resources to be used where they are most needed.

To use a branch simply grab a twig from the bookings page, file an IT bug to have your repo cloned over to your selected twig repo and then start pushing to the twig’s repo to see your builds start.  At the moment one small glitch is that the first push doesn’t get you any builds (bug 562026) – so you need to push twice on a fresh repo clone and the second set will get picked up by the hg poller.

I look forward to hearing if this setup helps you out.