Release:Release Automation on Mercurial:Plan

From MozillaWiki
Jump to navigation Jump to search

Release Automation on Mercurial

This page is a proposal for an automated release system for Gecko-based products in Mercurial. The process is based around our existing automation (Bootstrap) and manual processes around it.

Overview

[talk about not using custom buildbot steps]

Release Process

The automated process we follow for 1.8 and 1.9 builds looks like this: Release-automation-flowchart-current.png

This proposal suggests we alter the process to work as follows: Release-automation-flowchart-new.png

The reasoning behind these changes will be discussed in the sections below.

Tagging/branching

Deliverables

For all repositories involved in a release:

  • A named "release" branch that can be used if a respin is necessary (eg, GECKO191_20080724_RELBRANCH) which contains version bumps (eg, 3.1a1pre -> 3.1a1).
  • The above revision tagged for the current Build # (eg, FIREFOX_3_1a1_BUILD1)
  • The above revision tagged as _RELEASE (eg, FIREFOX_3_1a1_RELEASE)

Implementation Notes

  • The tree should be closed for the duration of this step to avoid any possibility of merge commits.
  • Should be implemented in a Buildbot BuildFactory as a series of ShellCommands.

Source tarball/bundle

Deliverables

  • A source tarball (.tar.bz2) of the code used to build a release without version control metadata.
  • A Mercurial bundle of the repository/repositories the product is built from. This is inclusive of the very first revision of the repository up to and including the revision tagged for this release.

This step explicitly does NOT happen for l10n repositories.

Implementation Notes

  • Generation of the packages should be implemented in a Buildbot BuildFactory as a series of ShellCommands and Mercurial checkout.
  • Pushing of the files to stage should be either a straight 'scp' ShellCommand, or a new Makefile target.

Build/Mars

There are two important changes from our existing build process here:

  • Generating partial mars right away, instead of with snippets.
  • Pushing builds in the same file/dir structure that we release them in.

Deliverables

  • Per platform, the appropriate package or installer.
  • Per platform, a complete mar file.
  • Per platform, a partial mar file against the previous release.

All of the files mentioned above should be named and stored in the format they will be released in.

Implementation Notes

  • The existing logic used for generating builds and complete mars for nightly builds should be moved to a BuildFactory. Release builds should use this factory to accomplish this task.
  • Partial mars should be generated using make_incremental_updates.py.
  • Pushing builds/mars to stage should be either a staright 'scp' ShellCommand or a new Makefile target.

l10n repack/mar generation

Deliverables

For every locale being shipped:

  • Per platform, the appropriate package or installer.
  • Per platform, a complete mar file.
  • Per platform, a partial mar file against the previous release.

Implementation Notes

TBD

Signing

Deliverables

For Windows builds:

  • Per locale, an installer with both its internal DLLs/EXEs signed AND the installer itself signed.

For Linux and Mac builds:

  • Per locale, a signed package.

Implementation Notes

  • sign-release.pl needs to support builds in the releases/ directory structure and name format.


l10n verification

Deliverables

  • diff output comparing (l10n vs en-US for the previous release) with (l10n vs en-US for the current release)

Implementation Notes

  • Should be implemented in a Buildbot BuildFactory as a series of ShellCommands.

Snippet generation

Deliverables

  • An updated and checked-in patcher config file.

For each platform/locale/channel combination:

  • A complete update snippet for all previous releases that ponits to the complete mar.
  • A partial update snippet for the most recent previous releases that points to the partial mar.
  • A partial update snippet for all other previous releases that points to the complete mar.

Implementation Notes

  • The logic that updates the patcher config file should be pulled out of Bootstrap and into a stand-alone script.
  • Should be implemented in a Buildbot BuildFactory as a series of ShellCommands.

Update/snippet verification

This step is two distinct tests. One ensures that updating from a partial mar has the same end result as updating from a complete mar. The other tests aus2 URLs on the 'betatest' channel to ensure all previous builds will be able to download a complete and/or partial mar.

Deliverables

  • An updated and checked-in configuration file for each platform.
  • Pass/fail notification of both tests mentioned above.
  • More detailed information when a failure occurs.

Implementation Notes

  • The logic that updates the configuration files should be pulled out of Bootstrap and into a stand-alone script.
  • Should be implemented in a BuildFactory in Buildbot as a series of ShellCommands.

Bouncer link verification

This test verifies that ensures bouncer is pointing to valid links for every combination of locale/platform/previous version. It must be run after there is good mirror saturation.

Deliverables

  • Pass/fail notification
  • Full, detailed log to aid analysis in case of failures

Implementation Notes

  • Should be implemented in a BuildFactory in Buildbot as a series of ShellCommands.

Releasetest/release snippet comparison

This test ensures that the release channel snippets are identical to the releasetest channel snippets.

Deliverables

  • Pass/fail notification
  • In the case of differences, a list of files that differ.

Implementation Notes

  • Should be implemented as a BuildFactory in Buildbot as a series of ShellCommands.
Retrieved from "https://wiki.allizom.org/index.php?title=Release:Release_Automation_on_Mercurial:Plan&oldid=101939"