Thunderbird/Release Driving/Rapid Release Activities/Merge Repositories: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(wip major update to latest)
(WIP more major udpates)
Line 1: Line 1:
== Setting up ==
== Setting up ==
{{Warning|The merge scripts download the comm-* repository bundles and create clones from those, and update them. These may use a large amount of data bandwidth to complete. This is done to ensure clean repositories.}}


You'll need access to:
You'll need access to:
Line 12: Line 14:


== Merges Overview ==
== Merges Overview ==
=== When merges happen ===


Merges should be done in the order:
Merges should be done in the order:
Line 18: Line 22:
* comm-aurora -> comm-beta
* comm-aurora -> comm-beta
* comm-central -> comm-aurora
* comm-central -> comm-aurora
=== When merges happen ===


The comm-beta -> comm-release merge is typically done a few days before the main merges. Normally the SeaMonkey folks determine when. At the latest it is done on Merge day.
The comm-beta -> comm-release merge is typically done a few days before the main merges. Normally the SeaMonkey folks determine when. At the latest it is done on Merge day.


The other two merges happen on Merge Day. This can be determined by looking at the [[RapidRelease/Calendar|release calendar]].
The other two merges happen on Merge Day. This can be determined by looking at the [[RapidRelease/Calendar|release calendar]].
On Merge Day, hook up with RelEng (mergeduty) to check when the mozilla-* repositories are being merged. These typically happen sometime in the morning Pacific Time - we aim to do the comm-* repositories '''after''' the mozilla-* ones, so that we don't have broken builds on the branches.


=== How to close the Trees ===
=== How to close the Trees ===
Line 29: Line 33:
Use [https://treestatus.mozilla.org/ treestatus] for closing trees. Set the "state" to CLOSED with a reason of "for merges" with the "Planned closure" tick box selected.
Use [https://treestatus.mozilla.org/ treestatus] for closing trees. Set the "state" to CLOSED with a reason of "for merges" with the "Planned closure" tick box selected.


For each merge ensure the relevant trees are closed, i.e. for comm-beta -> comm-release, ensure:
For each merge ensure the relevant trees are closed, e.g. for comm-beta -> comm-release, ensure:


** comm-beta-thunderbird
* comm-beta-thunderbird
** comm-beta-seamonkey
* comm-beta-seamonkey
** comm-release-thunderbird
* comm-release-thunderbird
** comm-release-seamonkey
* comm-release-seamonkey


=== Reopening the Trees ===
=== Reopening the Trees ===
Line 41: Line 45:


* For central: after the merges are completed and the version numbers have been bumped.
* For central: after the merges are completed and the version numbers have been bumped.
* For aurora, beta and release: after the merges are completed *and* the builds have been completed.
* For aurora: after the merges are completed *and* the builds have been completed.
* For beta: This remains closed after a comm-beta -> comm-release merge until after the comm-aurora -> comm-beta merge has been completed '''and''' the builds have been completed.
* For release: This remains closed as developers shouldn't be pushing to it.


When re-opening the tree, ensure you set it to the state that it was previously (generally "approval-required" for aurora/beta and "open" for central). There's a history on the page where you can check.
When re-opening the tree, ensure you set it to the state that it was previously (generally "approval-required" for aurora/beta and "open" for central). There's a history on the page where you can check.
== Doing the actual merges ==
These assume you've read the previous detail.
The scripts are run from the drivertools/comm-merges directory.
=== comm-beta -> comm-release ===
# Close the relevant trees
# Reset the repos (this removes any previous repository & creates a fresh clone)
  ./resetreleaserepos.sh
# Run the script
  ./merge-beta-2-release.sh &> beta2release.log
  less beta2release.log
# Check the log
When viewing the log check for:
* Outgoing tag to comm-beta
* The diff of changes committed to comm-release looks OK
* The outgoing changes to comm-release look ok, including closing of the old head, and tagging at the start and end of the list.
# Now push the beta tag (this doesn't cause any builds, as it doesn't change anything)
  hg -R beta push
# and the release builds (we generally haven't clobbered these as SeaMonkey's clobberer hasn't been up and running)
  hg -R release push -f


=== comm-aurora -> comm-beta merge ===
=== comm-aurora -> comm-beta merge ===
Line 98: Line 138:


  hg push -R aurora -f
  hg push -R aurora -f
Once the builders have run, check that you still have green builds.
=== comm-beta -> comm-release ===
Run the script
./merge-beta-2-release.sh &>beta2release.log
less beta2release.log
When viewing the log check for:
* Outgoing tag to comm-beta
* The diff of changes committed to comm-release looks OK
* The outgoing changes to comm-release look ok, including closing of the old head, and tagging at the start and end of the list.
When ready:
hg push -R beta
This won't cause anything to build, but will push the tag.
{{Note|It is best if the next part is done in association with the mozilla-beta to mozilla-release merge, but if you can't, kill off the builds once they start, and then clobber them.}}
Clobber the comm-release builds using [https://build.mozilla.org/clobberer/?branch=comm-release clobberer] and [http://seamonkey-clobberer.mozilla.org/?branch=comm-release seamonkey-clobberer]
Then push to comm-release:
hg push -R release -f


Once the builders have run, check that you still have green builds.
Once the builders have run, check that you still have green builds.
Line 142: Line 153:


Please commit and push any changes to the drivertools repo, for history purposes.
Please commit and push any changes to the drivertools repo, for history purposes.
=== Reopening trees ===
The Aurora and Beta trees are only normally re-opened to the approval state once the builders have cycled post merges and the trees are still in the previous state.
=== Hidden Builders ===
On tbpl, check that the list of builders is the same across the aurora/beta and then the central/aurora trees (via Tree Info -> Open Admin Tree Panel). Sometimes new builders are added, and only unhidden once green - this needs to be updated as the trains move along.

Revision as of 19:08, 30 March 2015

Setting up

Warning signWarning: The merge scripts download the comm-* repository bundles and create clones from those, and update them. These may use a large amount of data bandwidth to complete. This is done to ensure clean repositories.

You'll need access to:

  • Mercurial (level 3)
  • treestatus (one of the existing Thunderbird folks should be able to ask the Sheriffs to give you access).

Clone the drivertools repo 

hg clone http://hg.mozilla.org/users/bugzilla_standard8.plus.com/drivertools/
cd drivertools/comm-merges

Merges Overview

When merges happen

Merges should be done in the order:

  • comm-beta -> comm-release (used by SeaMonkey)
  • comm-aurora -> comm-beta
  • comm-central -> comm-aurora

The comm-beta -> comm-release merge is typically done a few days before the main merges. Normally the SeaMonkey folks determine when. At the latest it is done on Merge day.

The other two merges happen on Merge Day. This can be determined by looking at the release calendar.

On Merge Day, hook up with RelEng (mergeduty) to check when the mozilla-* repositories are being merged. These typically happen sometime in the morning Pacific Time - we aim to do the comm-* repositories after the mozilla-* ones, so that we don't have broken builds on the branches.

How to close the Trees

Use treestatus for closing trees. Set the "state" to CLOSED with a reason of "for merges" with the "Planned closure" tick box selected.

For each merge ensure the relevant trees are closed, e.g. for comm-beta -> comm-release, ensure:

  • comm-beta-thunderbird
  • comm-beta-seamonkey
  • comm-release-thunderbird
  • comm-release-seamonkey

Reopening the Trees

Reopening trees is only done when:

  • For central: after the merges are completed and the version numbers have been bumped.
  • For aurora: after the merges are completed *and* the builds have been completed.
  • For beta: This remains closed after a comm-beta -> comm-release merge until after the comm-aurora -> comm-beta merge has been completed and the builds have been completed.
  • For release: This remains closed as developers shouldn't be pushing to it.

When re-opening the tree, ensure you set it to the state that it was previously (generally "approval-required" for aurora/beta and "open" for central). There's a history on the page where you can check.

Doing the actual merges

These assume you've read the previous detail.

The scripts are run from the drivertools/comm-merges directory.

comm-beta -> comm-release

  1. Close the relevant trees
  2. Reset the repos (this removes any previous repository & creates a fresh clone)
 ./resetreleaserepos.sh
  1. Run the script
 ./merge-beta-2-release.sh &> beta2release.log
 less beta2release.log
  1. Check the log

When viewing the log check for:

  • Outgoing tag to comm-beta
  • The diff of changes committed to comm-release looks OK
  • The outgoing changes to comm-release look ok, including closing of the old head, and tagging at the start and end of the list.
  1. Now push the beta tag (this doesn't cause any builds, as it doesn't change anything)
 hg -R beta push
  1. and the release builds (we generally haven't clobbered these as SeaMonkey's clobberer hasn't been up and running)
 hg -R release push -f

comm-aurora -> comm-beta merge

Run the script 

./merge-aurora-2-beta.sh &>aurora2beta.log
less aurora2beta.log

When viewing the log check for:

  • Outgoing tag to comm-aurora
  • The diff of changes committed to comm-beta looks OK
  • The outgoing changes to comm-beta look ok, including closing of the old head, and tagging at the start and end of the list.

When ready: 

hg push -R aurora

This won't cause anything to build, but will push the tag.

Note: It is best if the next part is done in association with the mozilla-aurora to mozilla-beta merge

Clobber the comm-beta builds using clobberer

Then push to comm-beta: 

hg push -R beta -f

Once the builders have run, check that you still have green builds.

comm-central -> comm-aurora merge

Run the script 

./merge-central-2-aurora.sh &>central2aurora.log
less central2aurora.log

When viewing the log check for:

  • Outgoing tag to comm-central
  • The diff of changes committed to comm-aurora looks OK
  • The outgoing changes to comm-aurora look ok, including closing of the old head, and tagging at the start and end of the list.

When ready: 

hg push -R central
Note: It is best if the next part is done in association with the mozilla-aurora to mozilla-beta merge

Clobber the comm-aurora builds using clobberer

Then push to comm-aurora: 

hg push -R aurora -f

Once the builders have run, check that you still have green builds.

Central version bumps

Bump the versions in 

central/mail/config/version.txt
central/suite/config/version.txt

and commit with a message like "Version bumps for SeaMonkey and Thunderbird a=auroramerge".

Post-Merge tidy

Please commit and push any changes to the drivertools repo, for history purposes.

Retrieved from "https://wiki.allizom.org/index.php?title=Thunderbird/Release_Driving/Rapid_Release_Activities/Merge_Repositories&oldid=1065262"