Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti
1,529
edits
Release:Release Automation on Mercurial:Updates through Shipping: Difference between revisions
Release:Release Automation on Mercurial:Updates through Shipping (view source)
Revision as of 16:59, 11 December 2017
, 11 December 2017bm70 was decomm'd
(bm70 was decomm'd) |
|||
| (56 intermediate revisions by 10 users not shown) | |||
| Line 4: | Line 4: | ||
Deliverables: | Deliverables: | ||
* Updated patcher config file | * Updated patcher config file | ||
* | * Updated update verify configs | ||
* | * Release blobs submitted to production Balrog | ||
* Updated test channel rules in Balrog, pointing at the new release Blob | |||
After checking out the necessary modules and tools this builder goes to work doing the following: | After checking out the necessary modules and tools this builder goes to work doing the following: | ||
* Bumping & checking in a patcher config file | * Bumping & checking in a patcher config file | ||
* Creating & uploading update snippets | * Creating & uploading update snippets | ||
= Set-up whatsnew page = | = Set-up whatsnew page = | ||
At the time of writing, manual work is required if we're shipping a release that has a mix of old versions that need/don't need a whatsnew page. If Release Management hasn't specified that a whatsnew page is needed, there's nothing to do. This must be done after initial update submission is done, and you'll need to know which where the cut off line for the whatsnew is. For example, when 35.0 shipped everything earlier than 34.0 required a whatsnew page, but 34.0 and 34.0.5 did not. If you don't grok how Balrog rules work it would be a good idea [[Balrog#Rules | to read up on them]] before getting started here. | At the time of writing, manual work is required if we're shipping a release that has a mix of old versions that need/don't need a whatsnew page. If Release Management hasn't specified that a whatsnew page is needed, there's nothing to do. This must be done after initial update submission is done, and you'll need to know which where the cut off line for the whatsnew is. For example, when 35.0 shipped everything earlier than 34.0 required a whatsnew page, but 34.0 and 34.0.5 did not. If you don't grok how Balrog rules work it would be a good idea [[Balrog#Rules | to read up on them]] before getting started here. | ||
Note: do not modify blobs until both "updates" builders have finished. Your changes may be overwritten otherwise. | |||
To create a blob with the whatsnew page enabled, do the following: | To create a blob with the whatsnew page enabled, do the following: | ||
| Line 25: | Line 21: | ||
* Go to the "Releases" section. | * Go to the "Releases" section. | ||
* Find the release you're working on by filtering. | * Find the release you're working on by filtering. | ||
* Click " | * Click "Download". | ||
* Edit the local file and add the following at the top level of the blob (replace the VERSION variable with the version of the release, do NOT replace %LOCALE% or %OLD_VERSION% - those are substituted by Balrog/Firefox): | |||
* Edit the local file and add the following at the top level of the blob (replace | "openURL": "https://www.mozilla.org/%LOCALE%/firefox/$MANUALLY_REPLACE_THIS_VARIABLE_CALLED_VERSION/whatsnew/?oldversion=%OLD_VERSION%", | ||
"openURL": "https://www.mozilla.org/%LOCALE%/firefox/$ | |||
"actions": "showURL", | "actions": "showURL", | ||
* Change the "name" in the blob to something unique (usually by appending "-whatsnew" to it). | * Change the "name" in the blob to something unique (usually by appending "-whatsnew" to it). | ||
* Back in the Admin UI, click "Add a new release". | * Back in the Admin UI, click "Add a new release". | ||
* The name should match the one you just edited in the blob, | * The name should match the one you just edited in the blob, product should be Firefox. | ||
* Upload the new blob. | * Upload the new blob. | ||
| Line 80: | Line 75: | ||
= Check Permissions = | = Check Permissions = | ||
**only applicable for non release promotion releases** | |||
This builder: | This builder: | ||
# Checks if the FTP directories and files have proper permissions and modes | # Checks if the FTP directories and files have proper permissions and modes | ||
| Line 89: | Line 85: | ||
= Antivirus check = | = Antivirus check = | ||
**only applicable for non release promotion releases. release promotion bundles antivirus within beetmover tasks** | |||
This builder: | This builder: | ||
# Runs antivirus locally ''← report these results in build notes'' | # Runs antivirus locally ''← report these results in build notes'' | ||
| Line 103: | Line 99: | ||
= Push to mirrors = | = Push to mirrors = | ||
'''''only applicable for non release promotion releases''''' | |||
For GA release builds, this step is not run automatically, and must be manually triggered (below) after receiving the go from RelMgmt. For all other releases, this step is run automatically. | For GA release builds, this step is not run automatically, and must be manually triggered (below) after receiving the go from RelMgmt. For all other releases, this step is run automatically. | ||
* Release | * Release | ||
** [http://buildbot- | ** [http://buildbot-master71.bb.releng.use1.mozilla.com:8001/builders/release-comm-esr52-thunderbird_push_to_mirrors Thunderbird 52 Release] | ||
** | *** prerequisites: wait for driver email subj like 'push Thunderbird $version $buildnum to (release-cdntest channel|cdn|mirrors)' | ||
* | *** Note: update_verify automation emails should be completed | ||
* | |||
** | |||
This builder: | This builder: | ||
| Line 121: | Line 116: | ||
When enableAutomaticPushToMirrors is True, this is triggered automatically after the antivirus scan is done. When False, it must be manually triggered with Force Build. Step will automatically send email when complete. | When enableAutomaticPushToMirrors is True, this is triggered automatically after the antivirus scan is done. When False, it must be manually triggered with Force Build. Step will automatically send email when complete. | ||
The code used to be in | |||
[http://hg.mozilla.org/build/tools/file/tip/scripts/release/stage-tasks.py scripts/release/stage-tasks.py] (for historical revisions) but is now a [https://dxr.mozilla.org/mozilla-central/source/testing/mozharness/scripts/release/push-candidate-to-releases.py?q=path%3Apush-candidate-to-releases.py&redirect_type=single mozharness] script | |||
= Final Verification = | = Final Verification = | ||
**release promotion doesn't use ReleaseFinalVerification factory. it uses taskcluster and calls final-verification.sh directly** | |||
Code: | Code: | ||
* 'ReleaseFinalVerification' from [http://hg.mozilla.org/build/buildbotcustom/file/tip/process/factory.py process/factory.py] | * 'ReleaseFinalVerification' from [http://hg.mozilla.org/build/buildbotcustom/file/tip/process/factory.py process/factory.py] | ||
| Line 138: | Line 139: | ||
grep "HTTP/1.1 4" text | grep "HTTP/1.1 4" text | ||
grep "HTTP/1.1 5" text | grep "HTTP/1.1 5" text | ||
= Bouncer Submitter = | = Bouncer Submitter = | ||
This builder is triggered automatically after tagging completes, and creates and/or updates bouncer entries used on -cdntest and live update channels, and bouncer entries that Bedrock points at. | |||
This step adds adds bouncer entries for installers, complete and partial updates for all platforms listed in enUSPlatforms and l10nPlatforms and locales specified in shipped-locales (en-US is being added in any case). | This step adds adds bouncer entries for installers, complete and partial updates for all platforms listed in enUSPlatforms and l10nPlatforms and locales specified in shipped-locales (en-US is being added in any case). | ||
| Line 189: | Line 150: | ||
= Publish in Balrog = | = Publish in Balrog = | ||
'''''only applicable for non release promotion releases''''' | |||
== Betas/Final Releases == | == Betas/Final Releases == | ||
'''These instructions cover _typical_ cases. If any special requirements have been requested (ie, whatsnew page) you may need to do different or additional things at the same time.'''<br/> | '''These instructions cover _typical_ cases. If any special requirements have been requested (ie, whatsnew page) you may need to do different or additional things at the same time.'''<br/> | ||
We have a builder that updates the right parts of Balrog to push a release live. When instructed, you can use "force build" to start it. ( | Before publishing, you should verify that the throttle rate is set as expected - automation will not update this for you. Compare the rate in the push e-mail (eg: 25% or 100%) to the rate on [https://aus4-admin.mozilla.org/rules the Balrog admin interface]. More on throttle rates can be found in the [[#Throttling | Throttling section of this page]] | ||
We have a builder that updates the right parts of Balrog to push a release live. When instructed, you can use "force build" to start it. | |||
'''NOTE:''' this step requires a "double authorization" - appropriate sign off by QE or RelMan, ''and'' verifying that automation is ready (e.g. 'ready to ship' notification). | |||
Example buildbot URLs for the builder: | Example buildbot URLs for the builder: | ||
* [http://buildbot- | * [http://buildbot-master71.bb.releng.use1.mozilla.com:8001/builders/release-comm-beta-update_shipping_beta Thunderbird Beta] | ||
* [http://buildbot-master71.bb.releng.use1.mozilla.com:8001/builders/release-comm-esr52-update_shipping_release Thunderbird 52 Release] | |||
* [http://buildbot- | |||
''Note that the master you force this on, is not necessarily the master that takes the job, watch your e-mail for completion status. Subject will be "[https://github.com/mozilla/build-buildbot-configs/blob/master/mozilla/release_templates/update_shipping_success %(releaseName)s: Updates available on %(releaseChannel)s]".'' | |||
'''In order to guard against accidents, this builder aborts unless a special property is set. You must enter a "shipit" property on the form, whose value is also "shipit".''' | |||
= Throttling = | = Throttling = | ||
| Line 255: | Line 211: | ||
= Post-release tasks = | = Post-release tasks = | ||
'''''only applicable for non release promotion releases''''' | |||
Thunderbird is the only type of release that is non-release-promotion. After release is live, two more tasks need to be performed: marking them as shipped and run the BB post-release builder. They should be run at the same time, after release is live. | |||
== Mark as shipped on Ship It == | |||
Releases need to be marked as shipped on Ship It. To do so, visit https://ship-it.mozilla.org/releases.html, find the release in question, and click the "Shipped!" button. | |||
== postrelease builder == | |||
The "post release" builder needs to be started with "force build". This builder will update bouncer aliases. | |||
Example buildbot URLs for the builder: | Example buildbot URLs for the builder: | ||
* Beta | * Beta | ||
** [http://buildbot-master82.build.mozilla.org:8001/builders/release-comm-beta-thunderbird_postrelease Thunderbird Beta] | |||
** [http://buildbot-master82.build.mozilla.org:8001/builders/release-comm-beta-thunderbird_postrelease Thunderbird Beta] | |||
* Release | * Release | ||
** [http://buildbot-master82.build.mozilla.org:8001/builders/release-comm-esr52-thunderbird_postrelease Thunderbird 52 Release] | |||
** [http://buildbot-master82.build.mozilla.org:8001/builders/release-comm- | |||
''Note that the master you force this on, is not necessarily the master that takes the job, watch your e-mail for completion status. Subject will be "[https://github.com/mozilla/build-buildbot-configs/blob/master/mozilla/release_templates/default_success %(releaseName)s: completed %(stage)s]".'' | ''Note that the master you force this on, is not necessarily the master that takes the job, watch your e-mail for completion status. Subject will be "[https://github.com/mozilla/build-buildbot-configs/blob/master/mozilla/release_templates/default_success %(releaseName)s: completed %(stage)s]".'' | ||