The reports of Thunderbird's death have been greatly exaggerated.

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

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
  1. Go to Treeherder.
  2. Select the repo depending on the merge you want to perform (comm-central, comm-beta or comm-esrZZ).
  3. On the latest push, click on the down arrow in the top right corner.
  4. Select “Custom push action…”
  5. Choose merge-automation
  6. 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.
  7. 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
  1. Follow the general steps hopping on comm-beta
  2. 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
  1. Follow the general steps hopping on comm-central
  2. 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.

  1. Follow the general steps hopping on comm-esr115
  2. 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

  1. Email thunderbird-drivers that the merge is beginning using the template.
  2. Close comm-beta in Treestatus. 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”.
  3. Run the comm-beta -> comm-release no-op trial run one more time and verify the diff looks correct.
  4. 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.

  1. Upon successful run, comm-release should get a version bump, branding changes, and two new tags. The first tag should be in the form RELEASE_xxx_END - where the xxx is the previous major version. The other tag should be in the form RELEASE_yyy_BASE - where the yyy is the new major version.
  2. .gecko_rev.yml should have been modified to pin to the correct tag and rev on mozilla-release.
  3. At the same time comm-beta should get a tag in the form RELEASE_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

  1. Email thunderbird-drivers and tb-sheriffs that the merge is beginning using the template.
  2. Close comm-central in TreeStatus.
  3. On a local comm-central checkout, run mach tb-rust check-upstream. Make sure that you have the latest revision of both comm-central and mozilla-central. If that command reports that an update is needed, run mach tb-rust vendor and push the changes to comm-central before proceeding.
  4. Run the comm-central -> comm-beta no-op trial run one more time, and verify the diff looks correct.
  5. Submit a new task with force-dry-run set to false:
behavior: comm-central-to-beta
force-dry-run: false
push: true
  1. Upon a successful run, comm-beta should get a version bump, branding changes, and two new tags: BETA_xxx_END and BETA_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.

  1. Verify that mail/locales/l10n-changesets.json has revisions.

  2. At the same time comm-central should get a new tag BETA_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 in TreeStatus 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.

  1. Follow the general steps
  2. Run the comm-bump-central no-op trial run again and verify the diff looks correct.
  3. Insert the following payload and click submit.
behavior: comm-bump-central
force-dry-run: false
push: true
  1. Upon successful run, comm-central should get a version bump commit and a new tag NIGHTLY_xxx_END.

Bump ESR version (maybe)

Note

You could have one ESR to bump, or two. If you are not sure, ask.

Run the comm-bump-esr128 no-op trial run one more time, and verify the output.

Push your changes generated by the no-op trial run:

  1. Follow the general steps
  2. Insert the following payload and click submit.
behavior: comm-bump-esr128
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.

  1. Upon successful run, comm-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

Since June 2024 and bug 1899904, it is no longer necessary to update ShipIt when bumping the version on comm-central.