Sheriffing/How To/Merges: Difference between revisions

Jump to navigation Jump to search

Sheriffing/How To/Merges (view source)

Revision as of 20:44, 21 July 2017

375 bytes added ,  21 July 2017
no edit summary
No edit summary
No edit summary
Line 1: Line 1:
'''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''


''Goal: Merging around twice a 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.


'''Merges from the integration trees to mozilla-central are done on green PGO runs to avoid bustages on PGO which could affect as example Nightly Builds'''
= 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/How:To:SheriffingFromUnifiedRepos#Merges|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


= Step 1=
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 [https://treeherder.mozilla.org/#/jobs?repo=mozilla-central Treeherder]'''
Merging from autoland and mozilla-inbound to mozilla-central


Example mozilla-inbound to mozilla-central merge
== Merging back from mozilla-central to autoland and mozilla-inbound ==
  -> cd into your mozilla-central directory
Example mozilla-central to mozilla-inbound merge:
  -> hg pull ssh://hg.mozilla.org/integration/mozilla-inbound -r (the green with PGO runs inbound revision changeset) - also make sure there are no backouts  after that etc
  cd mozilla-unified
  -> hg merge && hg commit -m "merge inbound to mozilla-central"
  hg pull
  -> push
hg update inbound
  hg merge central
hg commit -m "Merge mozilla-central to mozilla-inbound"
  hg push -r . inbound


'''don't forget to use Bugherder after that! It's available from the menu for the push on [https://treeherder.mozilla.org/#/jobs?repo=mozilla-central Treeherder]'''
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


= Step 2 =
=== When there is nothing to merge ===
Merging back from mozilla-central to autoland and mozilla-inbound
You run <code>hg update</code> 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:


Example mozilla-central to mozilla-inbound merge
# Run <code>hg update</code>
-> go to your mozilla-inbound tree directory
#* You can run <code>hg out</code> to list all the changesets to merged to mozilla-central.
-> hg pull && hg update to make sure its the latest
# 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 [https://mozilla-releng.net/treestatus Treestatus] to be able to push.
-> hg pull ssh://hg.mozilla.org/mozilla-central/
# Push your changes from Step 1.
-> hg merge
# 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.
-> hg commit -m "merge mozilla-central to mozilla-inbound"
# Use Bugherder to mark and failures as usual for your push.
-> hg push
# Now when you merge from mozilla-inbound you get the note that you need to merge.
since this above might result in race conditions on the tree
(when its busy there) this works better ->
go to your mozilla-inbound tree
hg pull && hg update && hg pull ssh://hg.mozilla.org/mozilla-central/ && hg merge && hg commit -m  "Merge mozilla-central to [TREENAME]" &&  hg push
 
Aliases for the various repositories make the above easier to type!
 
= Step 3 hg update when there is nothing to merge =
 
You get the run 'hg update' to get a working copy information, because there where no changes on m-c and so nothing to merge. The workflow for this case is:
 
1.) Run hg update
-- If unsure if everything is ok just do a hg out, that should list all the changesets you want to sync to m-c
 
2.) because you do no merge and so have no commits like "merge a to b a=me" you would run into a hg hook telling you that the m-c repo is set to approval-only - so you need to temporary need to set the mozilla-central tree to "open" via tree-status to be able to push
 
3.) Push your changes from Step 1
 
4.) Set the m-c tree back to approval-required. 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 the bugs as usual
 
6.) now when you do the Steps from Step 1 with mozilla-inbound you get the note that you need to merge.
ChrisCooper
canmove, Confirmed users
2,850

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/1176275"

Navigation menu