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

From MozillaWiki
Jump to navigation Jump to search
(Bug 1082602)
Line 71: Line 71:
** Channel: nightly-esrNN
** Channel: nightly-esrNN
** Update type: minor
** Update type: minor
=== Update AUS2 ===
''These are legacy instructions, and should be deprecated when we stop uploading nightly snippets to aus3-staging.''
Adds new entries for nightly builds, Firefox only. See {{bug|808543}} for the details. Requires IT deployment (see {{bug|808543}}). Project and inbound branches usually do not have nightly builds.
Also need to create some symlinks for mac:
  ssh aus3-staging.mozilla.org    # using your ldap username, VPN running
  sudo su - ffxbld
  cd /opt/aus2/incoming/2/Firefox
  mkdir mozilla-esrNN            # where NN is your new version
  cd mozilla-esrNN
  ln -s Darwin_x86_64-gcc3 Darwin_x86_64-gcc3-u-i386-x86_64
  ln -s Darwin_x86_64-gcc3 Darwin_x86-gcc3-u-i386-x86_64


= Pull from mozilla-release =
= Pull from mozilla-release =

Revision as of 02:50, 24 February 2015


This process also works, with slight (obvious?) modifications for new twigs and b2g gecko branches. ESR17 process was tracked by bug 796995 and the dependent bugs. For ESR 24 is was bug 913195 for Firefox, and bug 913197 for Thunderbird. The process can be split into 2 major parts: internal and external

Internal changes

This covers changes to configs, buildbotcustom and tools.

buildbotcustom changes for ESR17 were not critical and are not ESR specific.

tools changes

tools changes

  • adds new release branch to production-masters.json file
  • adds new branch to buildapi's production-branches.json file
  • since the 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
  • mozconfig whitelist changes (tested in bug 808077)
  • preproduction tweaks

buildbot-configs changes

Some highlights:

  • 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
  • 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
  • for every exception (MERGE DAY exceptions) file a bug to track it
  • you may need to add shortening code for new branches

New release configs

  • Make sure that the following variables set
releaseConfig['partialUpdates'] = {}
releaseConfig['skip_updates'] = True
releaseConfig['verifyConfigs'] = {}
releaseConfig['ftpSymlinkName'] = 'latest-esr'
  • File new tracking bug for the next minor esr release (17.0.1esr) to update these variables
  • update previous release configs and set
releaseConfig['ftpSymlinkName'] = 'latest-10.0esr'
  • add mozilla2/*/comm-esr17/release/l10n-mozconfig for every platform. Copy them from mozilla-beta and compare to the previous esr configs
  • add mozilla2/linux/comm-esr17/release/mozconfig (linux only). We need this for source builder. Will be fixed by bug 748796

External changes

Ask IT to clone repos

See bug 807979 for the details. We usually clone ~1-2 weeks in advance off beta to test how automation works.

Add new branches to treestatus.m.o

Ask a treestatus admin to add the trees, or file a bug in Webtools::Tree Status. Notice that Thunderbird trees have -thunderbird suffix (comm-esr17-thunderbird). (as of bug 823618, tree addition & deletion require admin rights. Current admins include sheriffs, catlee, hwine. See bug 877948 for futures.)

Update tree closure hooks

See bug 807983 for the details (fyi, 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 slavealloc updates. (releng has add permissions, so IT deployment bug 808537 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

  1. File P1 bug against Treeherder to support the new repository. Ping in #treeherder if urgent.
    • Note that data for unknown repositories is ignored by Treeherder. Nothing breaks, but no data will be available.

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 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

Once mozilla-release is merged from mozilla-beta you can run the script which pulls last changes from mozilla-release, updates some configs and replaces some branding bits.

Running gecko_migration.py for mozilla-esr

EDIT configs/merge_day/release_to_esr.py and update ESR versions.

Example invocation:

# clone mozharness
hg clone http://hg.mozilla.org/build/mozharness
python mozharness/scripts/merge_day/gecko_migration.py -c mozharness/configs/merge_day/release_to_esr.py
  • the script will tag mozilla-release
  • it will continue by pulling mozilla-release to mozilla-esrNN, adjusting branding and changing some configs.
  • Once the script finishes, run an hg diff to see the uncommitted changes that the script generated:
(cd build/mozilla-esrNN; hg diff) | more
# an |hg out| will show the migrated changesets; an |hg out --patch| will show the patches for the migrated changesets.
  • It's best to get a visual review by someone else as well.
  • Commit+push the final bits by
# Make sure you already pushed your release version bump and reconfiged before this part!
python mozharness/scripts/merge_day/gecko_migration.py -c mozharness/configs/merge_day/release_to_esr.py --commit-changes --push

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

CI builds

Make sure to run all esr and some other builds in staging. Run leak test and nightly builds 2 times to allow them to generate leak log and partial updates.

Release builds

Make sure to run a staging release. It takes less time then usual build, because there are no updates to be generated.

Ship it!

Close the bug and have some tea. :)