Calendar:Release Build Instructions

Initial Preparation

• L10n lead needs to approve or reject any existing sign-offs for milestone on l10n dashboard.
• L10n lead needs to make sure shipped-locales is up to date (in comm-beta/comm-release).
• Release driver needs to determine the changesets & relbranches for the release.

Preparing for the builds

• Someone needs to hit the ship-it button on the dashboard for the milestone, and land the l10n changesets.
• Build needs to update release_calendar.py with:
  • Changesets and relbranches
  • version, appVersion, milestone (= gecko version), buildNumber, baseTag
  • The oldVersion, oldAppVersion, oldBuildNumber are usually updated, but it isn't vital in the current configuration.
• Check everything into buildbot-configs.

Starting the builds

• Clobber the calendar release builders (currently: 'tag', 'source', 'win32_build', 'macosx64_build', 'linux64_build', 'linux_build').
• ssh into the Calendar buildbot master
• Pull the latest configs and reconfigure the master:

$ cd calendar/buildbot-configs
$ # Check diffs
$ hg diff
$ # Check which revision you're on currently
$ hg identify
$ # Do the update
$ hg pull -u
$ # Check config
$ cd /buildbot/calendar
$ ./buildbot.sh checkconfig master.cfg
$ # and reconfig
$ ./buildbot.sh reconfig

• If you see "Reconfiguration appears to have completed successfully." then continue, else wait 5 minutes and then continue.
• Kick off the build, noting:
  • Branch should be releases/comm-beta or releases/comm-release as appropriate
  • The message in -m should be unique, otherwise buildbot may get confused.

$ ./buildbot.sh sendchange --username=<who you are> --master=localhost:9030 --branch=releases/comm-release -m "Lightning 1.1 final build 1 kick 1" doit

• At this stage, the master should show that the "tag" builder either has a build pending, or is running.
• If the tag build is pending, you might want to stop it using the buildbot web interface
• It is a good idea to check the comm-* and mozilla-* repositories during/after tagging to ensure the correct thing has been tagged and version bump is correct.

Post Build Step

• ssh into the 64 bit Linux box
• Run the following to unify the Linux builds (currently run in the home directory, should really move to be running on buildbot, there's a bug on that somewhere):

$ rm -r lightning*
$ # <version> is the version number e.g. 1.1, <build> is the build number e.g. 1.
$ sh fix_linux_xpi.sh <version> <build>

• Test the Lightning builds in the nightly/*-candidates directory
• Make sure the maxVersion is set to <major>.* instead of <major>.0
• Upload to AMO
• Notify the right people to create the Solaris contrib builds
• ssh to stage.mozilla.org to move files from <version>-candidates to releases/<version>. There is a script in the home directory that takes the same parameters as fix_linux_xpi.sh:

$ # <version> is the version number e.g. 1.1, <build> is the build number e.g. 1.
$ sh move_to_release.sh <version> <build>