Merge Duty
Merge Duty
Attention
This file replaces Merge Day Automation which is kept for historical purposes.
All code changes to Thunderbird land in the comm-central repository
- The
Daily
releases are built from that repo once a day. -
Beta
releases are built from the comm-beta repository -
Release
is built from comm-release repository -
Extended Support Releases
from the relevant ESR repo, such as comm-esr115
The merge in Merge Duty refers to the comm-beta-to-release
merge. All dates
referenced below are relative to Merge Day, which is 1 week before the
traditional Thunderbird merge-day, now known as version bump day.
Email templates
See Merge Email Templates for the email templates.
Overview of Procedure
- Prep work a week before the merge
- On Merge day:
- On Version Bump day, one week later:
Trial runs, one week prior to merge
Important
Doing a no-op trial run of each migration ensures that the migrations themselves work prior to Merge day.
General steps
- Go to Treeherder.
- Select the repo depending on the merge you want to perform (comm-central, comm-beta or comm-esrZZ).
- On the latest push, click on the down arrow in the top right corner.
- Select “Custom push action…”
- Choose
merge-automation
- In Treeherder, you'll see a new push show up in Treeherder in the repo you will be merging to. It can take a few minutes for the push and task to appear.
- Click on the merge or bump tasks (not the Gecko decision task). A job details panel will pop up and from there you'll find a link to the diff file in the artifacts tab. Note: There will be a cron job that kicks off another bump task with the same name, only one of them will contain the diff.
comm-beta->comm-release migration no-op trial run
- Follow the general steps hopping on comm-beta
- Insert the following payload and click submit.
behavior: comm-beta-to-release force-dry-run: true push: true
comm-central->comm-beta migration no-op trial run
- Follow the general steps hopping on comm-central
- Insert the following payload and click submit.
behavior: comm-central-to-beta force-dry-run: true push: true
comm-esr bump no-op trial run
comm-esr branches evolve over time: comm-esr115 is the current esr, and that is used in the discussion below; in the future, you may need to substitute a different esr version number.
- Follow the general steps hopping on comm-esr115
- Insert the following payload and click submit.
behavior: comm-bump-esr115 force-dry-run: true push: true
Release Merge Day - part I
When: The release merge must happen after Firefox has merged mozilla-beta to mozilla-release. For date, see Firefox Release Scheduling calendar.
Merge comm-beta to comm-release
- Email thunderbird-drivers that the merge is beginning using the template.
- Close comm-beta. Check “Remember this change to undo later”. Please enter a good message as the reason for the closure, such as “Mergeduty - closing beta for \$VERSION RC week”.
- Run the
comm-beta -> comm-release
no-op trial run one more time and verify the diff looks correct. - Submit a new task with
force-dry-run
set to false:
behavior: comm-beta-to-release force-dry-run: false push: true
Warning
If an issue comes up during this phase, you may not be able to run this command (or the no-op one) correctly. You may need to publicly backout some tags/changesets to get back in a known state.
- Upon successful run,
comm-release
should get a version bump, branding changes, and two new tags. The first tag should be in the formRELEASE_xxx_END
- where the xxx is the previous major version. The other tag should be in the formRELEASE_yyy_BASE
- where the yyy is the new major version. - .gecko_rev.yml should have been modified to pin to the correct tag and rev on mozilla-release.
- At the same time
comm-beta
should get a tag in the formRELEASE_xxx_BASE
- where the xxx is the previous major beta version.
Email thunderbird-drivers
Reply to the first email that the merge is complete using the template.
Release Merge Day - part II - a week after Merge day
When: The release merge must happen after Firefox has merged mozilla-central to mozilla-beta.
Merge central to beta
- Email thunderbird-drivers and tb-sheriffs that the merge is beginning using the template.
- Close
comm-central
in TreeStatus. - Run the
comm-central -> comm-beta
no-op trial run one more time, and verify the diff looks correct. - Submit a new task with
force-dry-run
set to false:
behavior: comm-central-to-beta force-dry-run: false push: true
- Upon a successful run,
comm-beta
should get a version bump, branding changes, and two new tags:BETA_xxx_END
andBETA_yyy_BASE
. .gecko_rev.yml is not pinned to the correct tag/revision. This should be done prior to building the new beta version.
Click the first HG revision link (left side under date and timestamp) for the merge push to verify this.
- Verify that
mail/locales/l10n-changesets.json
has revisions, notdefault
. - At the same time
comm-central
should get a new tagBETA_xxx_BASE
.
Warning
Be sure to pin .gecko_rev.yml to mozilla-beta's BUILD1 tag prior to promoting the beta 1 build.
Warning
The merge day automation may not be idempotent. The merge automation task may fail and auto-retry (because of a worker shutdown, for instance). If the task retries after updating the state of the repo, it will update the state of the repo again, pushing repeated commits.
Re-opening beta
Restore comm-beta tree
to its previous state (approval-required
) so that l10n bumper can run.
Tag comm-central and bump versions
What happens: A new tag is needed to specify the end of the nightly
cycle and bump versions in comm-central
.
- Follow the general steps
- Insert the following payload and click submit.
behavior: comm-bump-central force-dry-run: false push: true
- Upon successful run,
comm-central
should get a version bump commit and a new tagNIGHTLY_xxx_END
.
Bump ESR version
Note
You could have one ESR to bump, or two. If you are not sure, ask.
Run the comm-bump-esr115 no-op trial run one more time, and verify the output.
Push your changes generated by the no-op trial run:
- Follow the general steps
- Insert the following payload and click submit.
behavior: comm-bump-esr115 force-dry-run: false push: true
Note
The esr version is currently hardcoded to the action; If necessary, an action for other esr
versions can be added to taskcluster/ci/config.yml
.
- Upon successful run,
mozilla-esr${VERSION}
should get a version bump commit.
Reply to thunderbird-drivers that version bump completed
Reply to the migration request with the template.
Bump Nightly version and release dates in ShipIt
In ShipIt, the Thunderbird nightly version is hard-coded, and must be updated after the version bump on comm-central.
Follow these steps to bump the nightly version and release dates in ShipIt:
- Modify
api/src/shipit_api/common/config.py
and update theLATEST_THUNDERBIRD_NIGHTLY_VERSION
variable to be the new version of comm-central. - Create a pull request with the changes. Example
- In the pull request, @mention one of the Ship-It code owners to make sure the request is seen. You can also say something in #releaseduty on Matrix.
If you are not familiar with Github's Fork & Pull workflow model, see here for an introduction.