Release:Release Automation on Mercurial:Configuration

From MozillaWiki
Jump to: navigation, search

<< Documentation


Where possible (and where it makes sense to), the release configuration reuses variables from the branches' dep/nightly config. These will not be discussed here. This MXR query will show you all of the places in the release automation set-up that branch variables are referenced.

The release configs themselves have a number of variables and options in them. These are discussed below.


This variable is information dense dictionary and mostly contains information only relevant to Tagging. Each key of sourceRepositories (eg. "mozilla"), has a value of a dict with the following structure:

  • name - The name of the source repository, without any leading directories
  • clonePath - (staging only) Where to clone this repository from in repo_setup
  • path - Where to clone this repository for everything else (tagging, builds, repacks, et. al)
  • revision - The revision to base this release on. If relbranch is None or the provided one does not exist, the automation will update to this revision before creating the relbranch.
  • relbranch - The name of the relbranch to use for this release. If set to None, it will be generated automatically. If provided and exists, the automation will update to it before doing any bumping or tagging. If provided and doesn't exist, it will be created.
  • bumpFiles - This is another dict, whose keys are the paths in the sourceRepo, and whose values are *another* dict, with the following structure.
    • version - The version number to use in this file on the relbranch
    • nextVersion - The version number to use in this file on the default branch

Here's a concrete example of sourceRepositories for a Firefox build. Note that the bump file versions are typically factored out to earlier variables to avoid repetition.

releaseConfig['sourceRepositories'] = {
  'mozilla': {
    'name': 'mozilla-central',
    'path': 'mozilla-central',
    'revision': 'aaaaabbbbcccc',
    'relbranch': None
    'bumpFiles': {
      'browser/config/version.txt': {
        'version': releaseConfig['appVersion'],
        'nextVersion': releaseConfig['nextAppVersion'],
      'config/milestone.txt': {
        'version': releaseConfig['milestone'],
        'nextVersion': releaseConfig['nextMilestone'],


This variable is a dict that provides information about the versions that should receive a partial update to the current release. Each key of it is a version that partials are wanted for. The value is another dictionary, that must have 'appVersion', 'buildNumber', and 'baseTag' defined. See the table below for descriptions of those variables.


Variable Description
hgUsername The account name used when pushing tags, version bumps, and other configuration file updates back to repositories hosting on
hgSshKey The path to the ssh key to used when pushing things back to The username in hgUsername must be setup to accept this key in order for the automation to work correctly. Path is generally in the ~/ form in order to be platform independent.
l10nRepoClonePath This is exactly like sourceRepoClonePath, but is the root of the l10n repository directory used for cloning locale repos in repo_setup.
l10nRepoPath This is exactly like sourceRepoPath, but for locale repositories. http://hgHost/l10nRepoPath/ab-CD should be a cloneable repository.
l10nRevisionFile This is the path, relative to the master's directory, which contains a listing of all of the locales to build, and their changesets. This file is read in at buildmaster start/reconfig time and the information is passed along to ReleaseTaggingFactory, which tags all of the repositories for this release. Any subsequent steps which require a list of locales will pull them from shipped-locales. This is a bug that may or may not be fixed.
l10nRelbranch The relbranch to use for l10n repositories. See "relbranch" in the preceding section for mechanics. Generally should be set to the same thing as the sourceRepositories relbranches.
shippedLocalesPath The path, relative to the root of the sourceRepo, to shipped-locales.
mergeLocales When True, merging will be enable when running compare-locales.
l10nChunks The number of l10n builders to be used, per platform. If not present, defaults to DEFAULT_PARALLELIZATION set in process/
productName The lowercase product brand name. Eg, 'firefox', 'thunderbird', etc.
appName The lowercase application name. Eg, 'browser', 'mailnews', etc.
version/appVersion Sometimes we need the application version to be different from what we "call" the build, eg public release candidates for a major release (3.1 RC1). appVersion is an optional definition used in places that# don't care about what we call it. Eg, when version bumping we will bump to appVersion, not version. As a concrete example, when we produce the first release candidate for 3.1, version will be '3.1rc1' and appVersion will be '3.1'.
milestone The milestone version of the current platform release. Eg, 1.9.1b2
nextAppVersion/nextMilestone These variables control what the appVersion and milestone will be bumped to on the "default" branch.
buildNumber The build number of the current release. 1 if it's the first try for this release. May be 2, 3, or higher if respins were required.
baseTag The base tag to use when tagging repositories. _BUILD$buildNumber and _RELEASE will be appending to this where necessary.
enUSPlatforms This is a tuple containing all of the platforms that require an en-US build as part of the release. These platforms must exist in for the branch being built.
l10nPlatforms A tuple containing all of the platforms that require l10n repacks. Any platform listed here must also be listed in enUSPlatforms.
talosTestPlatforms A tuple containing all of the platforms that require talos test runs to be requested. Platforms listed here must also be listed in enUSPlatforms.
unittestPlatforms A tuple containing all of the platforms that require unit test runs to be requested. Platforms listed here must also be listed in enUSPlatforms.
xulrunnerPlatforms A tuple containing all of the platforms that require XULRunner builds to be generated.
patcherConfig The name of the patcher config file to bump and pass to
patcherToolsTag The tag to update both the tools and source repository to before running
ftpServer The ftp server to use for 'beta' channel snippets when useBetaChannel is '1'. Regardless of what useBetaChannel is set to this must be passed.
stagingServer The stage server to use for 'betatest' snippets and most verification tests.
bouncerServer The bouncer server to use for 'release' and 'releasetest' channel snippets.
ausServerUrl The AUS URL to aus for update verify tests.
ausUser The username to use when uploading snippets to the AUS server
ausSshKey The SSH key to use when uploading snippets to the AUS server
releaseNotesUrl URL of release notes. If None use the default URL. Introduced in bug 553059.
useBetaChannel This variable controls which channel is used as the final release channel. In order to not generate 'release' channel snippets (ie: for beta releases) set it to 0 so that the 'beta' channel snippets will be considered the final release channel, pointing to mirrors. When set to 1, 'release' channel snippets will be generated and will be considered the channel for final release, pointing to mirrors and if the patcher config has 'beta' channel references, beta snippets will be generated and will point to ftpServer, otherwise no beta snippets are generated.
*VerifyConfig The configuration file names for the update verify configuration files for each platform.
updateVerifyChunks The number of builders to be used for update verify, per platform. If not present, defaults to DEFAULT_PARALLELIZATION set in process/
testOlderPartials Applicable only to the "updates" step. When true, the update verify bumping step will mark the n-2 release to have both its partial and complete updates tested. When false, it will rely on the default behaviour of update verify (As of bug 514040, this is "test complete only for n-2 and earlier builds). Generally, should be True on 1.9.1 based releases and earlier and False on anything more recent.
doPartnerRepacks Whether or not to create and schedule partner repack builds as part of this release.
partnersRepoPath The repoPath of the repository containing the partner repack scripts and configs. Generally set to 'build/partner-repacks'. Only necessary when doPartnerRepacks is True.
AllRecipients List of email addresses to send step-by-step email notification of release progress, Defaults to release@
PassRecipients List of email addresses to send step-by-step email notification of release progress if and only if the step is successful, Defaults to release@, although we may want to send directly to r-d@
ReleaseTemplates Location of the message bodies to use to formulate the messages sent for the notifications
tuxedoConfig A configuration file of, which contains FTP path templates for the deliverables (installers and MARs). Examples: stable version, alpha (devpreview) version.
tuxedoServerUrl Tuxedo server's API URL prefix. Trailing slash is important.