|
|
| (7 intermediate revisions by 2 users not shown) |
| Line 38: |
Line 38: |
| } | | } |
| </pre> | | </pre> |
| | |
| | == partialUpdates == |
| | 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. |
|
| |
|
| == Others == | | == Others == |
| Line 70: |
Line 73: |
| | l10nChunks | | | l10nChunks |
| | The number of l10n builders to be used, per platform. If not present, defaults to DEFAULT_PARALLELIZATION set in [http://hg.mozilla.org/build/buildbotcustom/file/tip/process/release.py process/release.py]. | | | The number of l10n builders to be used, per platform. If not present, defaults to DEFAULT_PARALLELIZATION set in [http://hg.mozilla.org/build/buildbotcustom/file/tip/process/release.py process/release.py]. |
| |-
| |
| | cvsroot
| |
| | The cvsroot to use for pulling MozBuild, patcher tools, and other things from CVS. It is also used to check in an update patcher config file and as such must be an account with write access.
| |
| |- | | |- |
| | productName | | | productName |
| Line 79: |
Line 79: |
| | appName | | | appName |
| | The lowercase application name. Eg, 'browser', 'mailnews', etc. | | | The lowercase application name. Eg, 'browser', 'mailnews', etc. |
| |-
| |
| | binaryName
| |
| | The name which will be used in the filenames of installers, packages, and MARs. Usually is the same as productName.
| |
| |-
| |
| | oldBinaryName
| |
| | Same as above, but for the oldVersion.
| |
| |- | | |- |
| | version/appVersion | | | 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 and oldAppVersion are optional definitions 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'. | | | 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 | | | milestone |
| Line 100: |
Line 94: |
| | baseTag | | | baseTag |
| | The base tag to use when tagging repositories. _BUILD$buildNumber and _RELEASE will be appending to this where necessary. | | | The base tag to use when tagging repositories. _BUILD$buildNumber and _RELEASE will be appending to this where necessary. |
| |-
| |
| | oldVersion/oldAppVersion
| |
| | Same thing as version/appVersion, but applies to the previous release. When 3.1rc1 is shipped oldVersion and oldAppVersion will both be 3.1b3. When we ship 3.1.1 oldVersion will be, eg, 3.1rc2 and oldAppVersion will be 3.1.
| |
| |-
| |
| | oldBuildNumber
| |
| | The build number of the previous release. This should be the build number which was actually shipped.
| |
| |-
| |
| | oldBaseTag
| |
| | Same as baseTag, but for the previous release.
| |
| |- | | |- |
| | enUSPlatforms | | | enUSPlatforms |
| Line 160: |
Line 145: |
| | updateVerifyChunks | | | updateVerifyChunks |
| | The number of builders to be used for update verify, per platform. If not present, defaults to DEFAULT_PARALLELIZATION set in [http://hg.mozilla.org/build/buildbotcustom/file/tip/process/release.py process/release.py]. | | | The number of builders to be used for update verify, per platform. If not present, defaults to DEFAULT_PARALLELIZATION set in [http://hg.mozilla.org/build/buildbotcustom/file/tip/process/release.py process/release.py]. |
| |-
| |
| | majorUpdateRepoPath
| |
| | The relative path repository that contains the shipped-locales file for the major update "to" release. If None, the rest of the majorUpdate* variables are not necessary.
| |
| |-
| |
| | majorUpdateToVersion, majorUpdateAppVersion, majorUpdateBuildNumber, majorUpdateBaseTag
| |
| | These variables contain information about the release you are generating a major update to. See version/appVersion/buildNumber/baseTag for descriptions of them.
| |
| |-
| |
| | majorUpdateReleaseNotesUrl
| |
| | Major Update release notes URL. If None use the default URL. Introduced in {{bug|553059}}.
| |
| |-
| |
| | majorUpdatePatcherConfig
| |
| | The Patcher config file to use for the major update. This can be an existing file, in which case it will be overwritten and committed, or a non-existant file, in which case it will be created and committed.
| |
| |-
| |
| | majorUpdateVerifyConfigs
| |
| | See updateVerifyConfigs description above.
| |
| |- | | |- |
| | testOlderPartials | | | testOlderPartials |
| Line 200: |
Line 170: |
| | Tuxedo server's API URL prefix. Trailing slash is important. | | | Tuxedo server's API URL prefix. Trailing slash is important. |
| |} | | |} |
|
| |
| = Preparation =
| |
| There are a couple of things you can do prior to the "go to build" to hasten things when you do receive. Generally, we do the following ahead of time:
| |
| * Post updated configs and any other patches you'll need for review, using 'FILLMEOUT' or similar as the revision.
| |
| * Mark a clobberer for "Any master", $branch, "Any builder" with [https://build.mozilla.org/clobberer/ clobberer]. This will instruct any slave that did the last release on $branch to clobberer their release directories.
| |
|
| |
| If you are doing a test release in staging there is [[Release:Release_Automation_on_Mercurial:Documentation#Staging_Specific_Notes|additional setup work]] to do, and the clobberer URL changes.
| |
|
| |
| = L10N Changesets =
| |
| Currently we have separate changesets files for Fennec and Firefox. Both are generated from the [https://l10n.mozilla.org/shipping/milestones l10n dashboard]<br />
| |
| First log in to the dashboard with your LDAP and then follow the instructions below
| |
| ==Fennec==
| |
| * Click "ship it" to load up the milestone (eg: Fennec 8 Beta Build 2)
| |
| * This will take you to a page like [https://l10n.mozilla.org/shipping/confirm-ship?ms=fennec14_beta_b6 https://l10n.mozilla.org/shipping/confirm-ship?ms=fennec14_beta_b6]
| |
| * For 14.0b6+ for platforms use
| |
| android
| |
| * In the 'Add a multi-locale file for' field put
| |
| android-multilocale
| |
| * select "Add"
| |
| ** repo: "releases/mozilla-beta"
| |
| ** branch: "default"
| |
| ** path: "mobile/android/locales/maemo-locales"
| |
| * select "Generate it"
| |
| * Copy and paste it into your repo's l10n-changesets_mobile-{version}.json
| |
| * go back to the original page
| |
| * select "Ship it" to preserve the record of what was shipped
| |
|
| |
| ==Firefox==
| |
|
| |
| Note: these instructions also work for Thunderbird.
| |
|
| |
| * Click "ship it" to load up the milestone (eg: Firefox 8 Beta Build 2)
| |
| * This will take you to [https://l10n.mozilla.org/shipping/confirm-ship?ms=fx8_beta_b2 https://l10n.mozilla.org/shipping/confirm-ship?ms=fx8_beta_b2]
| |
| * Open in a new tab the "l10n-changesets" URL (don't touch any of the other fields) ''record the URL on the build notes''
| |
| * copy and paste the list into your l10n-changesets_mozilla-{version}
| |
| * go back to the original page
| |
| * select "Ship it"
| |
| ** <small>if you forget the URL, you can recreate the URL by judicious modification of the URL from the prior build notes</small>
| |
|
| |
| = Starting the automation =
| |
| Generally, the workflow for kicking off Release Automation is as follows:
| |
| * Update the configuration files
| |
| * Tag buildbotcustom <small>''(branch <tt>production-0.8</tt>)''</small>, buildbot-configs <small>''(branch <tt>production</tt>)''</small>, tools <small>''(branch <tt>default</tt>)''</small> with the correct _RELEASE and _BUILDn tags. You must use FIREFOX_${VERSION}_BUILDn and FIREFOX_${VERSION}_RELEASE for Firefox releases, FENNEC_${VERSION}_BUILDn and FENNEC_${VERSION}_RELEASE for Fennec releases, or all 4 tags for combined releases.
| |
| * Update the Buildbot Master doing the release
| |
| * Run the pre-flight sanity check. This is done in the master directory (watch out for PYTHONPATH). For example:
| |
| # Combined release
| |
| cd /builds/buildbot/build1/master
| |
| source ../bin/activate
| |
| PYTHONPATH=. python ../tools/buildbot-helpers/release_sanity.py -u bhearsum -V 6.0b2 --branch mozilla-beta --build-number 1 \
| |
| --release-config release-firefox-mozilla-beta.py --release-config release-fennec-mozilla-beta.py --products firefox,fennec \
| |
| --dryrun localhost:9001
| |
| # Firefox-only release
| |
| cd /builds/buildbot/build1/master
| |
| PYTHONPATH=. python ../tools/buildbot-helpers/release_sanity.py -u bhearsum -V 6.0b2 --branch mozilla-beta --build-number 1 \
| |
| --release-config release-firefox-mozilla-beta.py --products firefox \
| |
| --dryrun localhost:9001
| |
| * Start the automation by running the sanity script again, without --dryrun. For example:
| |
| # buildbot should in in $PATH, source ve env
| |
| source ../bin/activate
| |
| PYTHONPATH=. python ../tools/buildbot-helpers/release_sanity.py -u rail \
| |
| -V 6.0b2 --branch mozilla-beta --build-number 1 \
| |
| -c release-firefox-mozilla-beta.py -c release-fennec-mozilla-beta.py --products firefox,fennec localhost:9001
| |
|
| |
|
| |
| If you're working in staging you must make sure to pass in the correct staging release config (staging_release-firefox-<branch name>.py)
| |
|
| |
| If for some reason you need to perform the sendchange manually, here's a sample. Note that the branch name is the repo path to the source repository. In staging, this will be a user repo. All parameters are required:</p>
| |
| buildbot sendchange --username bhearsum --master localhost:9010 --branch releases/mozilla-release \
| |
| -p script_repo_revision:FIREFOX_3_6_12_RELEASE -p products:firefox,fennec release_build
| |
|
| |
| = Tree Merges (release driver) =
| |
| == Sync mozilla-beta to mozilla-release ==
| |
| Mercurial repositories used for final releases should be synced from mozilla-beta.
| |
|
| |
| Tip of default on mozilla-release should be tagged and closed. mozilla-beta should be tagged and pulled. It creates new tip of default on mozilla-release. See [http://mozilla.github.com/process-releases/draft/development_specifics/index.html#branching Aurora specific sync mechanics] for the details.
| |
|
| |
| L10N repositories uses noop (dummy) merge if needed to simplify localizers life.
| |
|
| |
|
| |
|
| |
| To handle this process use the following scripts.
| |
|
| |
| == Sync mozilla-beta to mozilla-release ==
| |
| [http://hg.mozilla.org/build/braindump/file/default/releases-related Script available here (beta2release.sh)] '''do not use as it doesn't update confvars.sh'''
| |
|
| |
| <pre>
| |
| # Adjust VERSION variable which stands for the current Firefox version in mozilla-release
| |
| VERSION=8
| |
| HG_USER="ffxbld <release@mozilla.com>"
| |
|
| |
| hg clone http://hg.mozilla.org/releases/mozilla-release
| |
| hg clone http://hg.mozilla.org/releases/mozilla-beta
| |
|
| |
| beta_rev=$(hg -R mozilla-beta id -i -r default)
| |
| release_rev=$(hg -R mozilla-release id -i -r default)
| |
|
| |
| RELEASE_BASE_TAG="RELEASE_BASE_`date +%Y%m%d`"
| |
| RELEASE_TAG="FIREFOX_RELEASE_$VERSION"
| |
|
| |
| hg -R mozilla-beta tag -r $beta_rev -u "$HG_USER" -m "Added tag $RELEASE_BASE_TAG for changeset $beta_rev. CLOSED TREE a=release DONTBUILD" $RELEASE_BASE_TAG
| |
| hg -R mozilla-beta push -e "ssh -l ffxbld -i ~/.ssh/ffxbld_dsa" ssh://hg.mozilla.org/releases/mozilla-beta
| |
|
| |
| hg -R mozilla-release tag -r $release_rev -u "$HG_USER" -m "Added tag $RELEASE_TAG for changeset $release_rev. CLOSED TREE a=release" $RELEASE_TAG
| |
| hg -R mozilla-release commit -u "$HG_USER" -m "Closing old head. CLOSED TREE a=release" --close-branch
| |
|
| |
| hg -R mozilla-release pull mozilla-beta
| |
| hg -R mozilla-release up -C default
| |
|
| |
| # edit shipped-locales file if you need to remove some beta locales
| |
| # edit confvars.sh:
| |
| -ACCEPTED_MAR_CHANNEL_IDS=firefox-mozilla-beta,firefox-mozilla-release
| |
| +ACCEPTED_MAR_CHANNEL_IDS=firefox-mozilla-release
| |
|
| |
| -MAR_CHANNEL_ID=firefox-mozilla-beta
| |
| +MAR_CHANNEL_ID=firefox-mozilla-release
| |
|
| |
| # commit the changes
| |
| hg -R mozilla-release commit -u "$HG_USER" -m "Updating confvars.sh CLOSED TREE a=release"
| |
|
| |
| # push back
| |
| # hg -R mozilla-release push -f -e "ssh -l ffxbld -i ~/.ssh/ffxbld_dsa" ssh://hg.mozilla.org/releases/mozilla-release
| |
| </pre>
| |
|
| |
| == L10N sync ==
| |
| [http://hg.mozilla.org/build/braindump/file/default/releases-related Script available here (beta2release_l10n.sh)]
| |
|
| |
| <pre>
| |
| #!/bin/bash
| |
| set -x
| |
| set -e
| |
|
| |
| HG_USER="ffxbld <release@mozilla.com>"
| |
| HG_HOST=hg.mozilla.org
| |
| repo=mozilla-release
| |
| release_repo_path=releases/l10n/mozilla-release
| |
| beta_repo_path=releases/l10n/mozilla-beta
| |
| wd=`pwd`/l10n
| |
|
| |
| mkdir -p $wd
| |
| cd $wd
| |
|
| |
| for l in `wget -q -O- http://$HG_HOST/releases/$repo/raw-file/default/browser/locales/shipped-locales | grep -v en-US | awk '{print $1}'`; do
| |
| hg clone http://$HG_HOST/$release_repo_path/$l
| |
| hg clone http://$HG_HOST/$beta_repo_path/$l $l.beta
| |
| release_rev=`hg -R $l id -i -r default`
| |
| beta_rev=`hg -R $l.beta id -i -r default`
| |
| hg -R $l pull $l.beta
| |
| hg -R $l up -C default
| |
| heads=`hg -R $l heads --template '{rev}\n' default|wc -l`
| |
| if [ "x$heads" != "x1" ]; then
| |
| hg -R $l up -C -r $beta_rev
| |
| HGMERGE=true hg -R $l merge -r $release_rev
| |
| hg -R $l revert -a -y --no-backup -r $beta_rev
| |
| hg -R $l commit -m "Merge from mozilla-beta" -u "$HG_USER"
| |
| hg -R $l commit -u $HG_USER -m "Merge from mozilla-beta. CLOSED TREE a=release"
| |
| fi
| |
| hg -R $l diff -r $beta_rev -r default
| |
| hg -R $l push -f -e "ssh -l ffxbld -i ~/.ssh/ffxbld_dsa" ssh://$HG_HOST/$release_repo_path/$l
| |
| done
| |
| </pre>
| |