ReleaseEngineering/How To/Create new ESR branch: Difference between revisions

no edit summary
No edit summary
Line 14: Line 14:
* Explicitly list the platforms (and use lock_platforms) since we don't ship ESR to all mozilla-central/release platforms (android, for example)
* Explicitly list the platforms (and use lock_platforms) since we don't ship ESR to all mozilla-central/release platforms (android, for example)
* Copy mozilla-beta configs, compare them to the previous ESR release and check if you understand what they stand for
* Copy mozilla-beta configs, compare them to the previous ESR release and check if you understand what they stand for
* No dep/nightly L10N builds required, as a result no need to create Tinderbox trees
* check mozilla-beta exceptions (loops) and check if they are aplicable to the current ESR
* check mozilla-beta exceptions (loops) and check if they are aplicable to the current ESR
* for every exception (MERGE DAY exceptions) file a bug to track it
* for every exception (MERGE DAY exceptions) file a bug to track it
Line 20: Line 19:
** make sure to run <tt>test-masters.sh</tt> to verify
** make sure to run <tt>test-masters.sh</tt> to verify
** see, e.g. https://hg.mozilla.org/build/buildbotcustom/annotate/b863ef3d9559/common.py#l128
** see, e.g. https://hg.mozilla.org/build/buildbotcustom/annotate/b863ef3d9559/common.py#l128
=== New release configs ===
* Make sure that the following variables set
releaseConfig['partialUpdates'] = {}
releaseConfig['skip_updates'] = True
releaseConfig['verifyConfigs'] = {}
releaseConfig['ftpSymlinkName'] = 'latest-esr'
releaseConfig['bouncer_aliases'] = {
    'Firefox-%(version)s': 'firefox-esr-latest',
}
* File new tracking bug for the next minor esr release (17.0.1esr) to update the first three of those variables
* update previous release configs to remove <tt>releaseConfig['bouncer_aliases']</tt>, and set
releaseConfig['ftpSymlinkName'] = 'latest-10.0esr'


== tools changes ==
== tools changes ==
Line 37: Line 24:
* adds new branch to buildapi's [http://hg.mozilla.org/build/tools/file/default/buildfarm/maintenance/production-branches.json production-branches.json] file
* adds new branch to buildapi's [http://hg.mozilla.org/build/tools/file/default/buildfarm/maintenance/production-branches.json production-branches.json] file
* mozconfig whitelist changes (tested in {{bug|808077}})
* mozconfig whitelist changes (tested in {{bug|808077}})
* preproduction tweaks
* since the [https://bugzilla.mozilla.org/attachment.cgi?id=678814&action=edit config patch] introduces new configuration file(s) which are needed to be symlinked on the build/scheduler masters there is a need for a fabric methods to create the links
* since the [https://bugzilla.mozilla.org/attachment.cgi?id=678814&action=edit config patch] introduces new configuration file(s) which are needed to be symlinked on the build/scheduler masters there is a need for a fabric methods to create the links
* adds new release branch to [http://hg.mozilla.org/build/tools/file/default/buildfarm/maintenance/production-masters.json production-masters.json] file
* adds new release branch to [http://hg.mozilla.org/build/tools/file/default/buildfarm/maintenance/production-masters.json production-masters.json] file
Line 55: Line 41:
== Update tree closure hooks ==
== Update tree closure hooks ==
See {{bug|807983}} for the details (fyi, [https://bugzil.la/816766#c1 ted has given us blanket approval] to land branch-name-only updates - have someone else double check). Requires deployment by IT (see {{bug|807694}}).
See {{bug|807983}} for the details (fyi, [https://bugzil.la/816766#c1 ted has given us blanket approval] to land branch-name-only updates - have someone else double check). Requires deployment by IT (see {{bug|807694}}).
'''TODO''': update this section because the hooks moved to https://hg.mozilla.org/hgcustom/version-control-tools/
== Update graphs.m.o and graphs.allizom.org with ==
Graph server schema changes. Requires both sql update ({{bug|808007}}) & deployment to both staging and production servers using a process similar to [[ReleaseEngineering:Buildduty:Slave_Management#Slavealloc|slavealloc updates]]. (releng has add permissions, so IT deployment <s>{{bug|808537}}</s> no longer needed except for deleting mistakes). (Use copy/modify/paste for all elements. Note that branch name is given in tbpl capitalization format.


== Update Treeherder ==
== Update Treeherder ==
Line 67: Line 48:
== Update Socorro ==
== Update Socorro ==
[https://bugzilla.mozilla.org/enter_bug.cgi?product=Socorro&component=General&short_desc=Add%20mozilla-esr%3CNN%3E%20and%20comm-esr%3CNN%3E%20to%20release_repositories&comment=A%20new%20ESR%20branch%20is%20being%20created,%20to%20support%20releases%20from%20there,%20Socorro%20needs%20to%20add%20mozilla-esr%3CNN%3E%20and%20comm-esr%3CNN%3E%20to%20the%20release_repositories%20table%20in%20PostgreSQL,%20see%20bug%201257651. File a Socorro bug] to have them add support for the new ESR branch (and its comm-esrNN equivalent).
[https://bugzilla.mozilla.org/enter_bug.cgi?product=Socorro&component=General&short_desc=Add%20mozilla-esr%3CNN%3E%20and%20comm-esr%3CNN%3E%20to%20release_repositories&comment=A%20new%20ESR%20branch%20is%20being%20created,%20to%20support%20releases%20from%20there,%20Socorro%20needs%20to%20add%20mozilla-esr%3CNN%3E%20and%20comm-esr%3CNN%3E%20to%20the%20release_repositories%20table%20in%20PostgreSQL,%20see%20bug%201257651. File a Socorro bug] to have them add support for the new ESR branch (and its comm-esrNN equivalent).
== Setup Nightly updates ==
=== Add rule to Balrog ===
NB: This should be done after the first set of nightlies (so that Firefox-mozilla-esrNN-nightly-latest exists, where NN is the new ESR version).
* login in to [https://aus4-admin.mozilla.org/rules.html Balrog]
* Add a new rule with
** Mapping: Firefox-mozilla-esrNN-nightly-latest
** BackgroundRate: 100
** Priority: 90
** Product: Firefox
** Channel: nightly-esrNN
** Update type: minor


= Pull from mozilla-release =
= Pull from mozilla-release =
Line 106: Line 73:


In case of failure, you can start again from the top; no need to clobber (the on-by-default clean-repos action will be sufficient).  It should be faster the second time, since you won't be pulling in as many changesets from hg.m.o.
In case of failure, you can start again from the top; no need to clobber (the on-by-default clean-repos action will be sufficient).  It should be faster the second time, since you won't be pulling in as many changesets from hg.m.o.


= Testing =
= Testing =
Confirmed users
3,104

edits