Sheriffing/How To/Merges

Goal

Each sheriff should perform a merge at the beginning of their work day. Effectively, this results in two sets of merges every day to/from autoland and mozilla-inbound to mozilla-central

Choosing a changeset to merge

For merges from the integration trees to mozilla-central, you should choose a changeset with a green PGO run to avoid bustages on nightly builds that also run PGO. You need to also make sure that are *NOT* any backouts *after* that changeset.

Order of operations

Integration branches should be merged to mozilla-central first, then mozilla-central should be merged back to the integration branches. These merge instructions were copied from Sheriffing From Unified Repos document.

Merging from autoland and mozilla-inbound to mozilla-central

Example mozilla-inbound to mozilla-central merge:

cd mozilla-unified
hg pull 
hg update central
hg merge -r <changeset> # the green changeset with PGO runs on mozilla-inbound
hg commit -m "Merge inbound to mozilla-central"
hg push -r . central

After you, be sure to use Bugherder to classify any failures on your merge commit. It's available from the menu for the push on Treeherder

Merging back from mozilla-central to autoland and mozilla-inbound

Example mozilla-central to mozilla-inbound merge:

cd mozilla-unified
hg pull
hg update inbound
hg merge central
hg commit -m "Merge mozilla-central to mozilla-inbound"
hg push -r . inbound 

These commands *might* result in race conditions on the tree when it is busy. Under those circumstances, this commands avoid delays between steps:

cd mozilla-unified
hg pull && hg update inbound && hg merge central && hg commit -m "Merge mozilla-central to mozilla-inbound" && hg push -r . inbound

When there is nothing to merge

You run hg update to get a working copy information, but there are no changes on mozilla-central and so nothing to merge. The workflow for this case is:

1. Run hg update
   • You can run hg out to list all the changesets to merged to mozilla-central.
2. Because there's been no merge, you won't have a commit containing a approval message, e.g. "merge a to b a=me." This means you will run afoul of the hg hook telling you that the m-c repo is set to approval-only. You need to temporarily set the mozilla-central tree to "open" via Treestatus to be able to push.
3. Push your changes from Step 1.
4. Set the m-c tree back to "approval-required" in Treestatus. This is important because if we miss this, we risk unexpected pushes to mozilla-central since some people might think the open tree is intentional.
5. Use Bugherder to mark and failures as usual for your push. If all bugs failed to get marked, entered Bugzilla API might be wrong. Close the tab and try with a new one. If only some failed, open Bugherder for that push again and append &resume=1 to the url.
6. Now when you merge from mozilla-inbound you get the note that you need to merge.

Issues

Push rejected: DOM peer review needed

(fix still needs to be verified in production) If the server rejects the push with the merge and complains that a changeset needs review by a DOM peer, you can disable this check. The issue should only affect merges with changesets which initially landed on autoland. Temporarily add this to the hgrc file in the .hg folder of the repository: mozilla.check.webidl_check = false