Monthly Archives: December 2011

Love Mozilla, Love Python, Want to Help, What Next?

I have been asked a few times over the last couple months how to help out at Mozilla, specifically with python.  I know there are dozens of teams within Mozilla that have various python related projects.  I am on the automation and tools team at Mozilla (known as the A*Team) and we do a lot of python related work.  It seems that we are asked to add new and crazy stuff to harnesses or write new and interesting tools (usually a blend of python and javascript).

1) Mozbase.  Our efforts in our spare time is to refactor our test harnesses within Mozilla to share common code where possible, we call it mozbase.  I recommend doing a git clone of mozbase and getting it installed on your system: git clone git@github.com:mozilla/mozbase.git

2) Talos.  Next is to pick up a test harness.  We have been focusing on talos.  Mostly because you don’t have to pull the entire mozilla-central tree, do hour long builds, and really because the talos code base is in need of some serious updating.  To get talos, you need to clone it: hg clone http://hg.mozilla.org/build/talos

3) Configure Talos.  Talos is run in 2 steps right now.  A configuration step and a execution step.  The configuration step requires a path to firefox.exe as well as an active test (I use ts to keep it simple) is pretty easy:  “python PerfConfigurator.py –develop -a ts -e <path>/firefox.exe –output mytest.yml”.

4) Run Talos.  this step is easy.  Make sure you don’t have another instance of firefox.exe running on the computer and then run: “python run_tests.py -d -n mytest.yml”.

5) Take a look at some of these bugs that we have which are related to mozbase and/or talos:  http://bit.ly/tZHs3G

While this isn’t exhaustive or a perfect guide for how to work on the perfect bug in an hour or less, these 5 steps should get you setup to work on basic Mozilla code and start fixing bugs!  Pop into #ateam on irc.mozilla.org and ask some questions.

Now back to the other PI(e) that I always talk about!

Leave a comment

Filed under Uncategorized

How the mobile automation for Android became reliable in the last few months

Making the Mozilla automation infrastructure run reliably for each checkin on mobile devices has been my primary focus for the last few years.  Last year at this time we were just trying to get Android automation up and running, all tools and harnesses had been written and ready to run.  The core buildbot code for running the tests was in place.  The problem was that we just had so many failures of the devices (NVidia Tegra development boards) and the tests.

So as the months went on from last December and up through August, we really made little progress.  A few tests were fixed, some disabled, some checks in place to make the boards stay online, but really no consistent set of test results.

There were a couple things that fixed our problems:

1) a rock star intern (:jchen) who found and fixed some workarounds with the OS so fennec wouldn’t crash all the time (issues with networking and libc).

2) a weekly meeting started by :blassey to go over all the bugs, status, issues, future work, and other items.

Both of these items are signs that the mobile development team was serious about testing and wanting to see Android unittests become a part of Mozilla.  While this seems trivial, it was next to impossible to keep tests running smoothly without support from the entire team.

Enjoy the reliable unit tests on Android!

Leave a comment

Filed under Uncategorized

TegraPool – Bathing suit not required

I have had the honor of working with Trevor on a few projects during his internship at Mozilla.  One of earlier projects he worked on was TegraPool, a utility to check out a tegra and run tests on it as we do on tinderbox.  Trevor doesn’t have a blog setup or a feed to planet, so here is what Trevor has to say:

A few weeks ago, I got nominated as a friend of a tree for being able to help out with mobile development get past issues with talos. Being a relatively new hire, I too am aware about how difficult it can be to get a testing environment set up, especially if you haven’t worked with mobile devices at all. Luckily, the first project I worked on this term is especially useful for those who can’t be bothered with setting up talos, or getting a Tegra and setting up the proper config for it.

Tegra Pool is an internal-only site for those who need to debug the issues in an automated testing run (such as on TBPL).  It can be found here: TegraPool. It will show you a table of all the devices available, and a couple forms to checkin and checkout.

If you are local and have the entire mobile testing suite set up, then it’s easy. Just put in your LDAP credentials and click “Check Out”. The IP of the Tegra you get will pop up, and not only will you be able to telnet and use the SUTAgent, but the AndroidDeviceBridge(ADB) will use TCP/IP, allowing you to connect with “adb connect <ip>”.

Remoties have a bit more of a problem, as most tests will require the Tegra to contact an “external server”, but we don’t want it to be making requests off-network. Also, many users don’t want to run the tests on their own computer, because they might need to run other things, or might not want to set up the entire testing environment. Luckily TegraPool solves these problems too.

If you are remote, or don’t have the time to set up the entire testing set, you can select the “I want server…” checkbox. To set up everything for you, you will have to point it to a test folder to get the app and zip files. This is best done with going to the build on Try in TinderBoxPushLog and clicking, “go to build directory”, when B is selected, and selecting the try-android-xul directory (or equivalent). Alternatively, ftp…mozilla-central-android  (or other folders in the nightly directory) is usually a good folder to use. This will set up a temporary account for you on the TegraPool server (based on your LDAP username).

Once you have checked out a Tegra and received a temporary account, you can now SSH into the machine (The password is a standard “giveMEtegra”). If you look in the home folder, you can see a lot of scripts that will just run. runMochiRemote.sh will run every single mochitest, runTalosRemote.sh will run the quick tpan test, and runRefRemote.sh will run the ref tests. If you connect to the device with ADB before running this, you should be able to pinpoint where issues are occurring.
This directory is a quick product, and should not limit what you can do. You can sftp new fennec.apk files, or modify the .sh files to run the necessary tests (i.e. other talos tests or specific mochitests).

Hopefully, this should let anybody who wants to debug mobile issues have a fast and easy option. Right now there are only 2 Tegra boards and 2 Panda boards running android, but if there is enough usage, more devices will be added. Happy debugging!

-Trevor (tfair on IRC)

Leave a comment

Filed under Uncategorized