Category Archives: Mozilla

As of the mozilla-inbound merge this morning, any time automation.py based tests timeout or crash, a screenshot will be base64 encoded and dumped into the test log on OS X. We’ve had this support for a while on Linux and I have matched the output format. In case you aren’t familiar with this, your logs will print out something that looks like:

8217 ERROR TEST-UNEXPECTED-FAIL | /tests/toolkit/content/tests/widgets/test_videocontrols.html | Test timed out.
args: ['/usr/sbin/screencapture', '-C', '-x', '-t', 'png', '/var/folders/Hs/HsDn6a9SG8idoIya6p9mtE+++TI/-Tmp-/mozilla-test-fail_k9Dpdz']
SCREENSHOT: data:image/png;base64,iVBORw0.....

If you want to see this image, copy everything from ‘data:image’, inclusive, to the end of line and paste it into your browser’s awesome bar.

In case you want to see what this looks like in the wild, here is a sample log with a screenshot.

I am working on getting this enabled on windows as well. My automation.py.in changes should easily support the win32 screenshot utility written by Ted in bug 414049.

This project has been discussed in a dev.planning thread, with the work being tracked in bug 658313.  We are going to be turning off PGO for incremental builds on all branches[1] on Wednesday, October 5, 2011.  In the exceedingly rare chance that you don’t read every single bug comment and dev.planning thread post, here is what will change:

• Builds triggered as part of a push will not have PGO enabled on any platform
• We will be producing builds every four hours with PGO enabled on Windows and Linux for the following branches:
• Mozilla-Inbound
• Mozilla-Central
• Mozilla-Aurora
• Mozilla-Beta
• All nightlies produced for platforms we ship PGO enabled (linux, windows) will have PGO on for the nightly build
• Platforms that we ship with PGO enabled will have their PGO talos results report to the current graphserver branch.  This includes nightlies and the new 4-hourly builds
• Platforms that we ship with PGO enabled will have their non-PGO talos results to a ‘-Non-PGO’ suffixed branch, e.g. Firefox-Non-PGO
• Platforms that we do not ship with PGO enabled will report both per-push builds and nightlies  to the current graphserver branch
• TBPL was modified in bug 670037 to make PGO builds special.  The deployment of these changes is being tracked in bug 691550.  If this TBPL change isn’t deployed before we start generating PGO builds, you might see duplicate build and test entries
• Yes, we plan to teach try chooser how to optionally do PGO.  For now, please include ‘mk_add_options MOZ_PGO=1′  in your PGO platform’s mozconfig-extra-$platform file if you wish to have PGO enabled for try.  Your results will be on the Try branch  in graphserver.  This work is being tracked in bug 691673
• Yes, we plan to optimize scheduling so that we only do a build if there has been a push in the previous four hours.  This might allow us to add PGO builds on more branches and is tracked in bug 691675

The motivation for this project is to get results to developers quicker.  It is felt that this reduction in PGO coverage is a safe optimization because there have been very few PGO related bugs found so far.

If you have any concerns, please contact me.  I am jhford in #build on irc.mozilla.org

[1] Well, all active development branches.  We are leaving PGO on for Win32 on branches older than Firefox 5, like mozilla-1.9.2

A while ago, we decided that we needed to expand our pool of machines to test Firefox on.  We are just about done getting the new 10.6 machines ready for production!  The machines we will be enabling are MacMini4,1 spec.  Internally, we are calling them ‘Rev4′ minis.

We won’t have all 80 of these minis ready for production right away, so we’ll start with ten.  Once we have 80 rev4 minis in production and every test suite is running reliably green on them, we will turn off the rev3 10.6 minis so they can be moved to other pools.  If there are suites that are orange, we will hide those results while we look into the failures.

In order to differentiate the talos results from these two different spec machines, we are creating a new platform on the graphserver.  When looking for data on graphserver, the platforms drop down will have two Mac OS X 10.6 options:

• MacOSX 10.6.2 (rev3)
• MacOSX 10.6 (rev4)

I have been working on getting our new Mac Mini (macmini4,1) machines ready to become Mac OS X 10.6 testing machines.  One of the last things needed before I start testing on a larger scale is a program to set the resolution on the command line.  We need this because our tests depend on having a specific resolution set.  Even if there was no dependency on a specific resolution, the GPU could perform differently depending on the size of the display it is working on.  As well, we run these minis without a real display so its really important that we have active confirmation that the desired resolution is set.

Previously, we used cscreen.  This is a utility that has fallen off the internet and was only ever released as a PowerPC binary.  I needed to decide between finding a replacement for cscreen and installing Rosetta.  While we currently have Rosetta on our testing slaves, I didn’t want us to depend on this.  This is because partly because I just don’t think its good hygiene and partly because I want to prepare for OS X 10.7, where Rosetta has been removed.  I searched the internet for a tool to do this, and sadly, there was nothing that fit the bill.  I tried alternatives like modifying the com.apple.Boot.plist file to specify resolution, but it didn’t work.  I also found some binary plist files that I could have edited and might have worked, but it seemed like a really flaky solution that would break *all* *the* *time*.  I decided that I’d have to write something to do this.

I did find a program that looked like it would be a good starting point, however, this program lacked any error checking.  Furthermore, when I investigated the APIs used, it looked like many of the important APIs were deprecated in 10.6 and would not be available in 10.7.  One particularly annoying deprecation was CGDisplayBestModeForParameters, because it takes the exact data I have (height, width and bit depth) and picked the best mode available.  In the end, I think I have a better solution that iterates through all modes and picks one that matches my inputs exactly.  I also noticed that CGDisplayBestModeForParameters doesn’t always return a mode that matches exactly to what was requestion, though, it does have facilities to deal with this case.

Alas, I started writing an application called screenresolution.  This program can be used to query the current and available resolutions as well as setting the resolution on one or more screens attached to the system.  This is my first C project in quite some time and I was never a C rockstar to begin with.  If you have a desire for Mozilla testing infrastructure to not suck and know C and CoreGraphics please slide on over to the source to check for issues!  I know that I could organize the code better and write a better command line interface, but I don’t think the benefits of that outweigh the cost of waiting even longer for these new machines.

I have posted thecode on my github account and have licensed it with the GPL v2 license in hopes that no one ever go through the search engine hell that was Friday Aug 26, 2011.  Below is a build of verison 1.3.  Why not 1.0?  Even though I wrote a test for the program, I neglected to actually run it. Multiple times   Once I started to actually run the tests, I started finding issues before bumping version numbers, gasp!

screenresolution-1.3.dmg

Update: Thanks Josh Aas and Richard Newman for reviewing my code and the great suggestions! I have a new version posted
screenresolution-1.4.dmg

Because this is a command line application, I recorded a video of my machine running the test suite.