Hunting the Shmoo

Getting Started

tl;dr - It is possible to add more mach to your B2G repo! To get started, install pip:

$ wget https://raw.github.com/pypa/pip/master/contrib/get-pip.py -O - | python

Install b2g-commands:

$ pip install b2g-commands

To play around with it, cd to your B2G repo and run:

$ git pull                 # make sure repo is up to date
$ ./mach help              # see all available commands
$ ./mach help <command>    # see additional info about a command

Details

Most people who spend the majority of their time working within mozilla-central have probably been acquainted with mach. In case you aren’t acquainted, mach is a generic command dispatching tool. It is possible to write scripts called ‘mach targets’ which get registered with mach core and transformed into commands. Mach targets in mozilla-central have access to all sorts of powerful hooks into the build and test infrastructure which allow them to do some really cool things, such as bootstrapping your environment, running builds and tests, and generating diagnostics.

Before now running ‘classic’ unittests (mochitest, reftest, xpcshell, etc.) on B2G emulators has been a massive pain. The new recommended way of running them is through mach.

1. Update B2G repo if you haven’t already: git pull
2. Configure an emulator: BRANCH=master ./config.sh emulator
3. Build: ./build.sh
4. Run: ./mach mochitest-remote

Hey! Check it out, I have crash stacks in my logs now! I know, I know, I took my sweet time. I’m sorry. I hope this doesn’t damage our relationship. Is there anything I can do to make it up to you? I want to help. I really do. It’s just. I don’t know. I guess I’ve been feeling under the weather lately. I must have caught a bug.

Throughout most of our B2G test automation deployment, we’ve been very conscious about not enabling too many tests simply because we didn’t have enough capacity on our test slaves to run them all. Regardless it was still bad enough as it was (many of you probably experienced very long wait times for results). Thanks to releng (and especially Rail Aliiev) we are now running most of our B2G tests in Amazon AWS which means we can be much more flexible in accomodating load.

As B2G continues to trod onwards to its release, there is still a lot of confusion about the level and state of test coverage it has. Back in November we started running mochitests, reftests and marionette/webapi tests on ARM emulators. Now we’ve also added xpcshell tests and for the most part we have these nice green letters to look at on TBPL that make us feel good about ourselves. But what is really being run? What is the meaning behind these letters “M”, “R”, “Mn” and “X”? Are there any causes for concern? Are there other tests being run that don’t show up on TBPL? What are the current automation priorities? What are the next platforms to use after emulators?

This blog post aims to answer these questions and more. It is a comprehensive snapshot of the current state of automated testing on B2G.

Contrary to popular belief, we (the A-Team) have been running mochitests, reftests, marionette tests and webapi tests on B2G in some form of continuous integration or another for about 5 months now. They’ve been reporting results to a TBPL look-alike called autolog, and were run on Amazon EC2 VM’s with emulators. This was a temporary solution to get something stood up quickly while we moved towards our ultimate B2G automation goal - tests running on Pandaboards and reporting to TBPL.

As of this week, while there are still no tests running on Pandaboards, I’m happy to say we have emulators running mochitests, reftests and marionette/webapi tests, all reporting to TBPL.

This quarter I’ve been focusing on getting reftests running on B2G, triaging them and fixing various issues. The purpose of this post is to outline their status, go over the work that still needs to be done and point out where I will need some help.