Sheriffing/How To/Merges: Difference between revisions
Jump to navigation
Jump to search
(add instructions to request missing tasks to get merge candidate if no merge since last Nightly builds) |
|||
| (8 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
{{Sheriffing How To|Merges}} | {{Sheriffing How To|Merges}} | ||
= Goal = | = Goal = | ||
'''Autoland''' | '''Autoland''' is a repository opened for developers who work on bug fixes, improvements and other. Merging means that clean code is transferred from Autoland to Central, and back if there are any changes Central might hold, but Autoland not. <br /> | ||
<span style="color:#14866d">'''''No sync is performed, only differences are transferred.'''''</span> | <span style="color:#14866d">'''''No sync is performed, only differences are transferred.'''''</span> | ||
= Choosing a changeset to merge = | = Choosing a changeset to merge = | ||
For merges from the integration trees to mozilla-central, you should choose a changeset with a green | For merges from the integration trees to mozilla-central, you should choose a changeset with a green Shippable run to avoid bustages on nightly builds that also run on Shippable. You need to also make sure that are *NOT* any backouts *after* that changeset. | ||
'''A more in depth view of the conditions a merge candidate must fulfill:''' | '''A more in depth view of the conditions a merge candidate must fulfill:''' | ||
#Candidate revision must be <span style="color:#14866d">'''100% completed'''</span> or <span style="color:#14866d">'''at least 98-99%'''</span>, with <span style="color:#14866d">'''maximum 15 jobs running'''</span>. | #Candidate revision must be <span style="color:#14866d">'''100% completed'''</span> or <span style="color:#14866d">'''at least 98-99%'''</span>, with <span style="color:#14866d">'''maximum 15 jobs running'''</span>. The candidate revision will have the Windows 10 Shippable opt suite and the complete Windows 10 opt suite. | ||
#<span style="color:#FF0000">'''No jobs classified as fixed by commit'''</span> | #<span style="color:#FF0000">'''No jobs classified as fixed by commit'''</span> | ||
#'''Few''' or '''no unclassified''' jobs | #'''Few''' or '''no unclassified''' jobs | ||
#Windows | #Windows 10 '''Shippable''' platform and Windows 10 '''opt''' must have <span style="color:#14866d">'''all jobs finished'''</span> (see screenshot as an example) | ||
[[File:Win10.png|center|windows 10]] | |||
#No backouts after merge candidate | #No backouts after merge candidate | ||
#If a merge candidate has more than 15 jobs running but they are autophone jobs, the candidate is good to use | #If a merge candidate has more than 15 jobs running but they are autophone jobs, the candidate is good to use | ||
If the planned merge is scheduled directly before Nightly builds will run on mozilla-central and there is no merge candidate and there hasn't been a merge to mozilla-central since the last Nightly builds ran, check if requesting all missing tasks for an autoland push has a good chance to turn it into a merge candidate. If that applies, request the missing tasks from the push's menu. | |||
Onboarding code sheriffs shall let the merge candidate they identified get checked by another sheriff. | |||
= Order of operations = | = Order of operations = | ||
| Line 20: | Line 25: | ||
'''Merge pattern:''' | '''Merge pattern:''' | ||
# autoland > central | # autoland > central | ||
# central > autoland <span style="color:#14866d">(if Central has changes Autoland might not)</span> | |||
# central > autoland | |||
# | |||
== Merging from autoland | == Merging from autoland to mozilla-central == | ||
Steps on how to do the <span style="color:#14866d">'''autoland | Steps on how to do the <span style="color:#14866d">'''autoland to mozilla-central'''</span> merge: | ||
# Have your revision ids ready | # Have your revision ids ready | ||
| Line 33: | Line 36: | ||
# Autoland to central merge command: <code>hg merge -r <span style="color:#14866d"><autoland_revision_id></span></code> | # Autoland to central merge command: <code>hg merge -r <span style="color:#14866d"><autoland_revision_id></span></code> | ||
# Add a commit message: <code>hg commit -m "Merge autoland to mozilla-central. a=merge"</code> | # Add a commit message: <code>hg commit -m "Merge autoland to mozilla-central. a=merge"</code> | ||
# Transfer the files to Central repo: <code>hg push -r . central</code> | # Transfer the files to Central repo: <code>hg push -r . central</code> | ||
After the | After the merge is in Central, <span style="color:#FF0000">'''bugs need to be marked with Bugherder'''</span>: go to Central and in the top right side of each of your pushes to Central, click on '''Action Menu''' (arrow button next to the pin button) and choose '''Mark With Bugherder'''. | ||
[[File:Bugherder tool.png|frame|center]] | [[File:Bugherder tool.png|frame|center]] | ||
Navigate through all the pages, check for any security bugs that can’t be updated by Bugherder and mention them to someone who can, check that Resolve and Fixed checkboxes are ticked and the correct version is set. At the last step click '''Submit''' and use your '''API key''' to finish the process. Leave the tab opened until the loadbar is not displayed anymore. | Navigate through all the pages, check for any security bugs that can’t be updated by Bugherder and mention them to someone who can, check that Resolve and Fixed checkboxes are ticked and the correct version is set. At the last step click '''Submit''' and use your '''API key''' to finish the process. Leave the tab opened until the loadbar is not displayed anymore. | ||
Announce in the sheriffing chat if there are bugs shown as restricted by Bugherder because the tool cannot access it and they need to be updated manually. Some of these bugs are also not accessible to code sheriffs. | |||
<span style="color:#14866d">'''Monitor the pushes and check that the Gecko Decision Task opt job is running. If it fails, rerun it, if it fails again the tree should be closed and the issue escalated.'''</span> | <span style="color:#14866d">'''Monitor the pushes and check that the Gecko Decision Task opt job is running. If it fails, rerun it, if it fails again the tree should be closed and the issue escalated.'''</span> | ||
== Merging back from mozilla-central to autoland | == Merging back from mozilla-central to autoland == | ||
Steps on how to do the <span style="color:#14866d">'''mozilla-central to autoland | Steps on how to do the <span style="color:#14866d">'''mozilla-central to autoland'''</span> merge: | ||
# Close | # Close autoland from [https://mozilla-releng.net/treestatus Treestatus] | ||
# In the console switch to Mozilla-unified directory: <code>cd mozilla-unified</code> | # In the console switch to Mozilla-unified directory: <code>cd mozilla-unified</code> | ||
# Download the repos: <code>hg pull fxtrees</code> | # Download the repos: <code>hg pull fxtrees</code> | ||
| Line 54: | Line 56: | ||
# Add a commit message: <code>hg commit -m "Merge mozilla-central to autoland. CLOSED TREE"</code> | # Add a commit message: <code>hg commit -m "Merge mozilla-central to autoland. CLOSED TREE"</code> | ||
# Transfer the files to Autoland: <code>hg push -r . autoland</code> | # Transfer the files to Autoland: <code>hg push -r . autoland</code> | ||
These commands *might* result in race conditions on the tree when it is busy. Under those circumstances, this commands avoid delays between steps: | 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 | cd mozilla-unified | ||
hg pull && hg update | hg pull && hg update autoland && hg merge central && hg commit -m "Merge mozilla-central to autoland" && hg push -r . autoland | ||
<span style="color:#FF0000">'''Note'''</span>: For correcting a commit message, use <code>hg commit --amend</code> | <span style="color:#FF0000">'''Note'''</span>: For correcting a commit message, use <code>hg commit --amend</code> | ||
| Line 75: | Line 73: | ||
# 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. | # 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. | ||
# 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 <code>&resume=1</code> to the url. | # 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 <code>&resume=1</code> to the url. | ||
# Now when you merge from | # Now when you merge from autoland you get the note that you need to merge. | ||
= Issues = | = Issues = | ||
| Line 84: | Line 82: | ||
<code>mozilla.check.webidl_check = false</code> | <code>mozilla.check.webidl_check = false</code> | ||
= Merges from central to beta etc. = | |||
These merges are done per release cycle to update the repository containing the code closer to the release repository with the code from the more development oriented repository. This merge is performed by the Release Engineering team. | |||
Latest revision as of 10:13, 23 November 2021
Goal
Autoland is a repository opened for developers who work on bug fixes, improvements and other. Merging means that clean code is transferred from Autoland to Central, and back if there are any changes Central might hold, but Autoland not.
No sync is performed, only differences are transferred.
Choosing a changeset to merge
For merges from the integration trees to mozilla-central, you should choose a changeset with a green Shippable run to avoid bustages on nightly builds that also run on Shippable. You need to also make sure that are *NOT* any backouts *after* that changeset.
A more in depth view of the conditions a merge candidate must fulfill:
- Candidate revision must be 100% completed or at least 98-99%, with maximum 15 jobs running. The candidate revision will have the Windows 10 Shippable opt suite and the complete Windows 10 opt suite.
- No jobs classified as fixed by commit
- Few or no unclassified jobs
- Windows 10 Shippable platform and Windows 10 opt must have all jobs finished (see screenshot as an example)
- No backouts after merge candidate
- If a merge candidate has more than 15 jobs running but they are autophone jobs, the candidate is good to use
If the planned merge is scheduled directly before Nightly builds will run on mozilla-central and there is no merge candidate and there hasn't been a merge to mozilla-central since the last Nightly builds ran, check if requesting all missing tasks for an autoland push has a good chance to turn it into a merge candidate. If that applies, request the missing tasks from the push's menu.
Onboarding code sheriffs shall let the merge candidate they identified get checked by another sheriff.
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.
Merge pattern:
- autoland > central
- central > autoland (if Central has changes Autoland might not)
Merging from autoland to mozilla-central
Steps on how to do the autoland to mozilla-central merge:
- Have your revision ids ready
- In the console switch to Mozilla-unified directory:
cd mozilla-unified - Download the Central repo:
hg pull central - Switch and update to it:
hg update central - Autoland to central merge command:
hg merge -r <autoland_revision_id> - Add a commit message:
hg commit -m "Merge autoland to mozilla-central. a=merge" - Transfer the files to Central repo:
hg push -r . central
After the merge is in Central, bugs need to be marked with Bugherder: go to Central and in the top right side of each of your pushes to Central, click on Action Menu (arrow button next to the pin button) and choose Mark With Bugherder.
Navigate through all the pages, check for any security bugs that can’t be updated by Bugherder and mention them to someone who can, check that Resolve and Fixed checkboxes are ticked and the correct version is set. At the last step click Submit and use your API key to finish the process. Leave the tab opened until the loadbar is not displayed anymore.
Announce in the sheriffing chat if there are bugs shown as restricted by Bugherder because the tool cannot access it and they need to be updated manually. Some of these bugs are also not accessible to code sheriffs.
Monitor the pushes and check that the Gecko Decision Task opt job is running. If it fails, rerun it, if it fails again the tree should be closed and the issue escalated.
Merging back from mozilla-central to autoland
Steps on how to do the mozilla-central to autoland merge:
- Close autoland from Treestatus
- In the console switch to Mozilla-unified directory:
cd mozilla-unified - Download the repos:
hg pull fxtrees - Update autoland:
hg update autoland - Merge from central to autoland:
hg merge central - Add a commit message:
hg commit -m "Merge mozilla-central to autoland. CLOSED TREE" - Transfer the files to Autoland:
hg push -r . autoland
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 autoland && hg merge central && hg commit -m "Merge mozilla-central to autoland" && hg push -r . autoland
Note: For correcting a commit message, use hg commit --amend
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:
- Run
hg update- You can run
hg outto list all the changesets to merged to mozilla-central.
- You can run
- 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.
- Push your changes from Step 1.
- 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.
- 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=1to the url. - Now when you merge from autoland 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
Merges from central to beta etc.
These merges are done per release cycle to update the repository containing the code closer to the release repository with the code from the more development oriented repository. This merge is performed by the Release Engineering team.