SeaMonkey:Release Automation

From MozillaWiki
Jump to: navigation, search

The SeaMonkey 2 release automation process builds upon Mozilla's Mercurial-based release automation by reusing the generic buildbot factories from buildbotcustom as much as possible and subclassing it where needed.


SeaMonkey 2 release automation runs on the same buildbot master and slaves as the other SeaMonkey builds and unit tests. Currently, this affects the new Parallels-based systems that are not fully in production yet.

Final Deliverables

The most important deliverables are the packages, installers, and updates. This includes (for each locale)

  • Linux tarball, Mac dmg, Windows installer (exe)
  • Complete and partial MAR file
  • Update snippets for test and live channels

Other, less important deliverables include:

  • Source tarball
  • Langpacks per platform per locale (minus en-US)
  • Release branch and tags on appropriate repositories

Source packages are used by a small number of individuals and some Linux distributions to do their own builds of SeaMonkey. Release branches and tags are very important to Release Automation and also used by developers when a release must be respun.

Individual steps may have additional deliverables which only serve to feed later steps. These are discussed in the Mozilla release automation doc.

Current Status

As of July 15, 2009, the code is working for tagging, source tarball, builds, L10n repackaging, creating partial updates as well as snippets and update verification. l10n_verify couldn't be fully tested as there haven't been any localized previous releases. All the work is available in buildbotcustom, hg build tools, cvs tools repos with the UPDATE_PACKAGING_R9 tag or the SeaMonkey buildbot configuration. bug 493451 is tracking the efforts to have everything fully working, the only missing things are doing a real release run with that config and moving some CC classes to buildbotcustom.

Getting things going


Very similar to Release:Release_Automation_on_Mercurial:Documentation#Configuration but with a few added variables, currently only documented in itself.

Starting the automation

Generally, the workflow for kicking off Release Automation is as follows:

  1. Update l10n-changesets (normally performed by someone from the l10n team days ahead of time)
  2. Update
  3. Reconfigure the buildbot master
  4. Kick-off automation with the following command:
buildbot sendchange --username=kairo --master=localhost:9010 --branch=users/ -m "SeaMonkey 2.0a4build1" doit

Of course, replacing username, branch, and the message appropriately. Be sure not to leave out --branch.



SeaMonkey release automation tags all of the affected comm and Mozilla repos, inspector, venkman, and localizations on Mercurial as well as ChatZilla on CVS. For Chatzilla, no relbranch is created, we just do static tags at a given dated version from CVS trunk.


We have no signing infrastructure for SeaMonkey right now, so we fake the signing step that is usually done after completion of builds and L10n repacks and before the update generation.

We log onto and use those commands to do the following:

# seabld@stage-old
cd /home/ftp/pub/seamonkey/nightly/${VERSION}-candidates/build${BUILD}
mkdir win32 update/win32
rsync -av --exclude=*.zip unsigned/win32/ win32/
rsync -av unsigned/update/win32/ update/win32/
rsync -av unsigned/win32_info.txt .
echo "faked" > win32_signing_build${BUILD}.log

We purposely make copies here rather than symlinking for a couple of reasons: L10n verify scripts barf when they get zip files (hence the --exclude above), 'updates' factory will blow away complete MARs upon upload if update/win32 is a symlink. The echo creates the log the automation looks for, in order to continue to l10n verify and updates.