Release:Release Automation on Mercurial:Starting a Release: Difference between revisions

Jump to navigation Jump to search

Release:Release Automation on Mercurial:Starting a Release (view source)

Revision as of 16:39, 21 January 2013

2,382 bytes removed ,  21 January 2013
no edit summary
No edit summary
Line 46: Line 46:
* Copy and paste the list into your changesets file (eg: l10n-changesets_mozilla-{version})
* Copy and paste the list into your changesets file (eg: l10n-changesets_mozilla-{version})


= Clobbering =
= Submit to Ship It =
Mark a clobberer for "Any master", $branch, "Any builder" with [https://secure.pub.build.mozilla.org/clobberer/ clobberer]. This will instruct any slave that did the last release on $branch to clobberer their release directories. Ideally, this should be done hours or more before the release starts, so that cleanup occurs before the release job starts. Clobbering isn't mandatory if your release config has base_clobber_url pointing to always_clobber.php.
Releases are initiated through the [https://ship-it-dev.allizom.org/ Ship It webapp]. When you're ready to start a release, you can use the [https://ship-it-dev.allizom.org/submit_release.html "Submit a new release" page] to submit it. Once it's in the system you should find '''someone else''' to review it for you. They can see it and mark it as ready on [https://ship-it-dev.allizom.org/releases.html the "View releases" page]. If multiple releases are expected around the same time it's often best to wait until all are ready for review, so that they can be started at the same time.


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.
= Run Release Runner =
After your release has been submitted and reviewed you need to run release runner, which will create the patches, run release sanity, reconfig, and start the release. You can do this with the following.
ssh -A cltbld@buildbot-master36
screen
bash run_release_runner.sh


= Post a Patch for Review =
If you hit any errors that you don't know how to debug on your own, ask someone for help.


Note: Firefox releases also include Fennec unless otherwise specified.
If you have any failures after configs or tags have been pushed you won't be able to restart release runner without commenting out some sections of it. If you don't know how to do this, ask for help.
 
Once {{bug|810393}} is fixed, this will happen without manual intervention.
For a Firefox beta, you'll need to modify:
 
mozilla/l10n-changesets_mobile-beta.json
mozilla/l10n-changesets_mozilla-beta
mozilla/release-fennec-mozilla-beta.py
mozilla/release-firefox-mozilla-beta.py
 
= Land patches and reconfig =
Just like any other buildbot-configs change you would make you should start by landing your patch on the "default" branch of the repository. After that, there's a few other things that need to be done to prepare for a release:
* Transplant your change to the "production" branch. Usually done with something like:
cd buildbot-configs
hg up -r production
hg transplant [rev of commit on "default"]
* Tag repositories with release tags. buildbot-configs should have the tag applied to the tip of the "production" branch. buildbotcustom should have it applied to the tip of the "production-0.8" branch, and tools should have it applied to the tip of the "default" branch. For example, Firefox 17.0b1 would required FIREFOX_17_0b1_BUILD1, FIREFOX_17_0b1_RELEASE, FENNEC_17_0b1_BUILD1, and FENNEC_17_0b1_RELEASE applied.
* [[ReleaseEngineering/Landing_Buildbot_Master_Changes | Reconfig]] the build and scheduler masters.
 
= Running release sanity and starting the automation =
On the build scheduler master (see <tt>production-masters.json</tt>, currently bm36) run release sanity in dry run mode. For example (updated for multi-master):
# Combined release
cd /builds/buildbot/build_scheduler/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:9301
# Firefox-only release
cd /builds/buildbot/build_scheduler/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 --products firefox  \
  --dryrun localhost:9301
# Thunderbird release:
cd /builds/buildbot/build_scheduler/master
source ../bin/activate
PYTHONPATH=. python ../tools/buildbot-helpers/release_sanity.py -u hwine \
  -V 14.0b5 --build-number 1 --branch comm-beta \
  --release-config release-thunderbird-comm-beta.py --product thunderbird \
  --dryrun localhost:9301
 
After that succeeds (or you account for any failures you receive), run the command again without --dryrun to start the release. Some standard discrepancies:
* for chemspills: to bypass l10n checks if not changing, add option "<tt>-l</tt>"
* for Thunderbird: to bypass (broken) mozconfig checks, add option "<tt>--bypass-mozconfig-check</tt>"
 
If you're working in staging you must make sure to pass in the correct staging release config (staging_release-firefox-<branch name>.py)
Bhearsum
canmove, Confirmed users
6,439

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/503314"

Navigation menu