SeaMonkey:Release Automation
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.
Contents
Overview
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
Configuration
Very similar to Release:Release_Automation_on_Mercurial:Documentation#Configuration but with a few added variables, currently only documented in release_config.py itself.
Starting the automation
Generally, the workflow for kicking off Release Automation is as follows:
- Update l10n-changesets (normally performed by someone from the l10n team days ahead of time)
- Update release_config.py
- Reconfigure the buildbot master
- Kick-off automation with the following command:
buildbot sendchange --username=kairo --master=localhost:9010 --branch=users/kairo_kairo.at/comm-central -m "SeaMonkey 2.0a4build1" doit
Of course, replacing username, branch, and the message appropriately. Be sure not to leave out --branch.
Steps
Tag
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.
Signing
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 stage-old.mozilla.org and use those commands to do the following:
# seabld@stage-old
VERSION=2.0a4
BUILD=1
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.
