Tl;dr: it's now easier to run multilocale builds locally. I'd love feedback in terms of whether this is useful for you, and if there are changes that would make this script better for your workflow.

I updated the wiki as well.

what & why

There are only three ways to get a multilocale build currently:

• triggering a nightly build off of a multilocale-enabled branch,
• pinging me directly and asking for a multilocale build, or
• building multilocale locally. Up until now, that involved a combination of digging through logs, asking for help, and reverse-engineering the multilocale script with a lot of trial and error.

The latter was so difficult because I hadn't spent the time to make it friendly to run locally. Now that bug 753545 has landed, it should now be relatively easy.

The config file is written to [hopefully] be easily editable and usable.

running the script

• Create a directory to run in. It's simplest to create a new directory, although you can use an existing directory with mozilla-central (or other tree) already checked out.

  mkdir multilocale
  cd multilocale
  

• Clone mozharness and copy the standalone config file for easy editing+use.

  hg clone http://hg.mozilla.org/build/mozharness
  cp mozharness/configs/multi_locale/standalone_mozilla-central.py myconfig.py
  

• Customize your config file.

  By default it's going to clone mozilla-central into a directory called mozilla-central.

  It also assumes your objdir will be named objdir-droid and that will be specified in your mozconfig, which will be in a file named mozconfig in this directory.

  This should hopefully be easy to edit. Holler if it's confusing.

  Afterwards, you can verify it's still valid python by typing

  python myconfig.py
  

  which should exit silently.

• If your config file still says that your mozconfig is in os.path.join(os.getcwd(), "mozconfig"), copy your mozconfig into this directory and make sure it's named mozconfig.
• Make sure mozilla-central (or whatever repo you specified) is in this directory.

  You can either clone it manually, or use the script's pull-build-source action:

  mozharness/scripts/multil10n.py --cfg myconfig.py --pull-build-source
  

• Run the script.

  By default, this will:

  • pull the locale source,
  • copy your mozconfig into the tree and build mozilla-central,
  • package the en-US apk,
  • backup your objdir to a -bak directory (e.g. objdir-droid-bak) via rsync,
  • restore your objdir via rsync (no changes),
  • add the locales to your objdir,
  • and package the multilocale build.

  (See the actions section below for more advanced usage.)

  mozharness/scripts/multil10n.py --cfg myconfig.py
  

developing + debugging

The above instructions are sufficient for when you want a single multilocale build.

If you're changing m-c code or otherwise want multiple builds, you probably want to follow this workflow:

• After running the multilocale steps, you want to restore your objdir to en-US. At least until someone figures out how to clobber the multilocale-specific bits, rsyncing from a clean backup directory seemed like the most expedient solution.

  mozharness/scripts/multil10n.py --cfg myconfig.py --restore-objdir
  

• Then make your code changes.
• Then run the default actions again. If this seems like it's doing more than it needs to, you're correct. See the actions section below for more advanced usage.

  mozharness/scripts/multil10n.py --cfg myconfig.py
  

actions

(I covered actions to some degree here as well, but the below specifically covers this script + config file.)

what actions are available?

You can see the default actions, defined in the config file, by:

mozharness/scripts/multil10n.py --cfg myconfig.py --list-actions


This will give you this output:

Actions available: clobber, pull-build-source, pull-locale-source, build, package-en-US, upload-en-US, backup-objdir, restore-objdir, add-locales, package-multi, upload-multi
Default actions: pull-locale-source, build, package-en-US, backup-objdir, restore-objdir, add-locales, package-multi


what do these actions do?

I'd like to have more information about each action built into each script. Here's an overview of multil10n.py's actions:

• clobber - This is effectively no-op as long as work_dir is set to '.'. Otherwise it nukes the entire work_dir.
• pull-build-source - This clones the repos defined in repos.
• pull-locale-source - This clones the repos defined in l10n_repos, as well as the l10n repositories defined in the locales file (specified here)
• build - This copies the mozconfig path specified here into the source tree, and runs make -f client.mk build.
• package-en-US - This runs make package.
• upload-en-US - To be written. It will call make upload.
• backup-objdir - This rsyncs your objdir to a backup directory, since there's no current solution for clobbering the multilocale bits in your objdir.
• restore-objdir - This rsyncs the backup directory into your objdir. If you want to re-run the build or re-add the locales without a lot of old cruft lying around, I recommend doing this first.
• add-locales - This runs compare-locales and adds the locale strings + manifests into your objdir.
• package-multi - This runs make package for your multilocale apk.
• upload-multi - To be written. It will call make upload.

how do I run a single action?

You can run any single action by itself by prepending -- in front of the action name (making it a command line option). For instance, to only run the restore-objdir action,

mozharness/scripts/multil10n.py --cfg myconfig.py --restore-objdir

how do I skip an action?

You can run the default set of actions, minus an action, by prepending --no- to the action(s) you want to skip. To run the default actions without pulling the locale source,

mozharness/scripts/multil10n.py --cfg myconfig.py --no-pull-locale-source

how do I run several actions at once?

Running the script with no action-specific command line options will iterate over the list of default actions.

You can also have a combination of --ACTION or --no-ACTION to add an action to or remove an action from the default list. For example,

mozharness/scripts/multil10n.py --cfg myconfig.py --no-pull-locale-source --no-build --no-package-en-US --no-backup-objdir

and

mozharness/scripts/multil10n.py --cfg myconfig.py --restore-objdir --add-locales --package-multi

are equivalent.

You also have the option of editing your default_actions in myconfig.py if that makes things easier.

Firefox 6.0b2 is the first combined release: Firefox desktop and Firefox for Mobile running in the same automation, run by the same release engineer.

I remember talking about this with John O'Duinn in pie-in-the-sky brainstorming sessions back in Building K a few years ago, back before Fennec 1.0. It seemed so far away, then. It's a bit surreal seeing it run now.

A large part of the team chipped in on this one, but Rail did most of the heavy lifting. Thank you Rail!

In case John's branching blog post was tl;dr:

[1]: We're still debating whether we're going to merge mobile-browser in.

[2]: We're using the same set of l10n-mozilla-2.0 repos for both Firefox 4.0.x and Fennec 4.0.x.

We've been thinking about changing our mobile upload logic for a while now.

1. "mobile-trunk" and "mobile-1.9.2" were effective enough abstractions, but forced us to translate those back to branch names in automation,

2. uploading all platforms to the same directory resulted in same-named files being overwritten by subsequent builds (e.g. the windows l10n repack overwriting the linux l10n repack's xpi files), and

3. old versions of the same files would hang around in the latest nightly directories after a version bump. Or, in the case of the Maemo deb files, every build would upload a differently-named deb.

The first two issues should be solved now that bug 579097 has landed. Instead of stuffing everything into latest-mobile-trunk/, we're using a branch-platform naming structure.

This structure should also allow us to solve issue #3 elegantly. We're currently copying new files into a directory with existing files, with the assumption that they'll overwrite each other. This, of course, breaks when the filename changes. And adding per-file cleanup logic tends to be complex or messy or both.

If, instead, the latest-* directories were softlinks to the latest dated directory (e.g. latest-mozilla-central-maemo4 -> 2010/07/2010-07-20-13-mozilla-central-maemo4/), there would be no old files to clean up. I'm a big fan of directory-level upload logic, because of things like this.

This is on my radar; not written yet. Tracked in bug 580495.

So where are the builds? Still in the nightly directory. But the layout's a bit different.

For trunk (mozilla-central), look here:

Android	latest-mozilla-central-android-r7/
Maemo 5 GTK (Fremantle)	latest-mozilla-central-maemo5-gtk/
Maemo 5 QT (Fremantle-QT)	latest-mozilla-central-maemo5-qt/
Maemo 4 (Chinook)	latest-mozilla-central-maemo4/
Linux Desktop	latest-mozilla-central-linux/
MacOSX Desktop	latest-mozilla-central-macosx/
Windows Desktop	latest-mozilla-central-win32/

For 1.1.x nightlies (mozilla-1.9.2), look here:

Maemo 5 GTK (Fremantle)	latest-mozilla-1.9.2-maemo5-gtk/
Maemo 4 (Chinook)	latest-mozilla-1.9.2-maemo4/
Linux Desktop	latest-mozilla-1.9.2-linux/
MacOSX Desktop	latest-mozilla-1.9.2-macosx/
Windows Desktop	latest-mozilla-1.9.2-win32/

Depend builds are still in the misnamed tinderbox-builds directory, and the Maemo nightly update repositories are still in the same place.

Maemo N810 talos and unit tests are currently available on the TraceMonkey tree.

In a way, this is a pooling win. Once Lukas enabled the TraceMonkey Maemo builds, I refactored the mobile buildbot configs and made a few tweaks to get TraceMonkey tests running and reporting using the existing device pool. And now we can catch Maemo breakage before it lands in mozilla-central.

There are some known issues:

1. Fennecmark (Tzoom and Tpan) seems to break the other non-Tp tests. Once I disabled it and removed the jar, the other test suites started running. (bug 506181)

2. Reftest seems to be broken. When I had a device in front of me, I saw the unresponsive script prompt, which may explain that. No bug yet.

3. Mochitests are broken on both m-c and TraceMonkey. (bug 503439)

4. There aren't enough devices to keep up. This is a multi-part issue.

Currently each checkin spawns 10 test suites, the longest of which takes nearly four hours. Afterwards it takes up to a half hour to reboot and reconnect. If we assume a maximum of one checkin in either branch per four and a half hours, 10 functional devices would fully keep up with all checkins.

Of course, it's unrealistic to expect developers to throttle their checkins in m-c and TraceMonkey to one checkin per four and a half hours. Unfortunately, it's also currently unrealistic to expect ten devices to be up and running at any one time. Currently there appear to be 4 functional N810s in production.

The devices weren't really designed to be an enterprise 24/7 test platform, as evidenced by these Maemo bugs. Adding the stress of running constant tests designed for desktops, and my own undiscovered setup bugs, and we lose several (3-6?) devices a night.

Why not buy more? We were considering a pool of 50; if half fell over we'd still be able to handle a large number of builds. The N810 and Diablo might not be the final configuration we end up targeting. Also, until recently, keeping the devices up required hours of daily imaging work.

John Ford recently solved bug 502762, creating a custom image for the N810s, which is awesome. There's still a bunch of testing and ironing out to be done, but this should be a massive time saver. Still, this doesn't allow us to keep up with multiple checkins on multiple branches. Or keep devices up overnight. Just bring them back up faster the next day.

I heard rumblings of wanting Maemo tests on Try. This would add even more load than an additional branch, as Try builds don't allow for build skipping.

We're tracking the N810 stabilization issue in bug 499334. We're working on this while also trying to port tests to two new platforms, and possibly dealing with a new Maemo device. Or, as I call it, 3-5 quarters' worth of work in one quarter's time.

First off, hats off to John Ford, who finished try server mobile builds. Now Firefox developers will have better insight as to whether their patch breaks Maemo and WinCE Fennec builds *before* the patch is committed.

Also, I was struck by how many builds now live on the Mobile tree. Only a handful of months ago (February), joduinn posted this to mark the second column on the tree. Now, the full set (noignore=1) of builds looks like this:

(click?)

(Complete with oranges and broken 1.9.1 builds. We're working on that.)

Finally, this is possibly the end of the Nokia pedalboard, at least as it's currently set up. It's served its purpose well, and has been a definite attention-getter here in building K. But there's an air conditioned shelf reserved in the machine room for the n810s. I suppose we'll see if Windows Mobile devices take over the pedalboard or if I retire it from active mobile device duty.

A jug of wine, a loaf of bread, a slightly used guitar pedalboard, some velcro, a swiftly growing number of Nokia N810s and N800s running automated Fennec performance and unit tests via buildbot, and thou...

... Can you get started on the wine&bread without me? I'm right in the middle of this script. Be right there.