Release:Release Automation on Mercurial:Tagging through Signing

From MozillaWiki
Jump to: navigation, search

<< Documentation

Tag

Code used:

Deliverables:

  • Release branch and tags on source and l10n repositories ← for build notes, find from hg just after scripts run (e.g. beta)

This steps creates an in-repo branch and tags in both source and locale repositories. For example, if you started Release Automation for Firefox 3.1b3 on January 17th, 2009 (building out of the mozilla-1.9.1 repository) you would end with the following in mozilla-1.9.1 and all appropriate l10n repositories:

  • GECKO191_20090117_RELBRANCH named branch.
  • FIREFOX_3_1b3_BUILD1 tag
  • FIREFOX_3_1b3_RELEASE tag

For source repositories, after creating the branch Release Automation will perform a version bump to ensure that the release will be versioned correctly. After commiting this, it will be tagged with both of the FIREFOX_* tags and pushed back from whence it came.

For l10n repositories the exact revisions give in l10n-changesets are used as the branch point *and* tagged with the FIREFOX_* tags. They do not require a version bump.

For combined or Fennec-only releases the "tag" builder starts tagging in parallel and creates the following branches/tags in mozilla and l10n repositories:

  • Release branch with MOBILE prefix
  • FENNEC_${VERSION}_BUILDn tag
  • FENNEC_${VERSION}_RELEASE tag

Source / Fennec Source

Code:

Deliverables:

  • Source bundle and tarball uploaded to the staging server.

Creates a ready-to-be-built tarball and ready-to-be-used Mercurial bundle of the sourceRepo. These files will be uploaded to the candidates directory in the 'source' subdirectory.

Build

Code:

Deliverables:

  • Desktop (Firefox)
    • en-US build for each platform (tarball for Linux and Linux64, dmg for Mac, exe and zip for Windows) uploaded to the staging server
    • en-US complete MAR files for each platform uploaded to the staging server
    • *_info.txt files containing BuildID uploaded to the staging server
    • .checksums files containing sha512 sums of all files uploaded
    • debugging symbols uploaded to the symbol server
  • Mobile (Fennec)
    • en-US and multi APKs for Android platforms uploaded to the staging server
    • en-US build for each mobile desktop platform (tarball for Linux, dmg for Mac, exe and zip for Windows) uploaded to the staging server
    • *_info.txt files containing BuildID uploaded to the staging server
    • .checksums files containing sha512 sums of all files uploaded
    • debugging symbols uploaded to the symbol server

This step happens per item in enUSPlatforms and follows the nightly build process very closely. Notable differences are:

  • Updates to the _RELEASE tag prior to building
  • Uses a different mozconfig

Talos & Unittests

Not run anymore.

L10n Repack

Code:

Deliverables:

  • A build for each platform/locale combination (except Android and Maemo5)
  • A complete MAR file for each platform/locale combination (except Fennec)
  • Partial MARs for each platform/locale combination
  • A langpack (.xpi) file for each platform/locale combination (except Android and Maemo5)
  • .checksums file containing sha512 sums for all uploaded files

Repacks are done across a set of Builders per platform. The number of Builders per platform is controlled by the 'l10nChunks' release config variable, with a default set as DEFAULT_L10N_CHUNKS in process/release.py. Each Builder performs one Build; each Build repacks (totalLocales / l10nChunks) locales.

Chunked repacks

You can rebuild a failed repack job, and all the locales will be redone (overwriting the previous files). However, you should consider using a standalone repack builder if only select locales from the chunk need a respin.

Standalone Repack Builders

We sometimes run into the case where individual locales need to be re-spun. The easiest way to do this without re-spinning the entire chunk that failed is to use the standalone repack builder through the 'force build' form. By convention the standalone builder name ends in "_standalone_repack". You will need to enter the following fields and properties for the builder to succeed:

  • properties:
    • locale (A colon separated list of locales to respin)
    • script_repo_revision (you should also use the _RELEASE tag here)

If you've used the standalone builder to recover from failed locales, and that was successful, then you need to use "force build" on that platform's "repack complete" builder. This will allow the automation to continue.

Partner Repack

Code:

Deliverables:

  • A full set of unsigned partner repacks, uploaded to the staging server

This step is only done as part of releases on the latest stable branch. It uses unsigned en-US and l10n builds to create partner repacks.

Signing

Signing happens at build/repack time with the signing server.

Retrieved from "https://wiki.mozilla.org/index.php?title=Release:Release_Automation_on_Mercurial:Tagging_through_Signing&oldid=1172580"