Sheriffing/How To/Backouts: Difference between revisions

add actions for backouts of bugless commits
(→‎Best Practices and Communication: add reminder to mention issues with backed out change detected later)
(add actions for backouts of bugless commits)
 
(5 intermediate revisions by 2 users not shown)
Line 25: Line 25:


===== Example on how to backout a single revision =====
===== Example on how to backout a single revision =====
'''Note:''' The example below is for inbound, but the same steps should be followed for any repos
'''Note:''' The example below is for autoland, but the same steps should be followed for any repos
# close the tree
# close the tree
# <code>cd mozilla-unified</code>
# <code>cd mozilla-unified</code>
# <code>hg pull inbound </code>
# <code>hg pull autoland</code>
# <code>hg update inbound </code>
# <code>hg update autoland</code>
# identify the revision we want to backout (e.g. def0af88e262)
# identify the revision we want to backout (e.g. def0af88e262)
# <code>hg oops -er def0af88e262 </code>
# <code>hg oops -er def0af88e262 </code>
# open the text editor to add the description of the backout, e.g.: “Backed out changeset def0af88e262 (bug 1359017) for <insert reason here> CLOSED TREE”.
# open the text editor to add the description of the backout, e.g.: “Backed out changeset def0af88e262 (bug 1359017) for <insert reason here> CLOSED TREE”.
# <code>hg push -r . inbound </code>
# <code>hg push -r . autoland</code>


===== Example on how to backout multiple revisions =====
===== Example on how to backout multiple revisions =====
'''Note:''' The example below is for inbound, but the same steps should be followed for any repos
'''Note:''' The example below is for autoland, but the same steps should be followed for any repos
# close the tree
# close the tree
# <code>cd mozilla-unified </code>
# <code>cd mozilla-unified </code>
# <code>hg pull inbound </code>
# <code>hg pull autoland </code>
# <code>hg update inbound </code>
# <code>hg update autoland </code>
# identify the push we want to backout. E.g.: 478cffed4b5f, daea2bcda8cb, 9abaf5195566, 2f665a0a379f
# identify the push we want to backout. E.g.: 478cffed4b5f, daea2bcda8cb, 9abaf5195566, 2f665a0a379f
# <code>hg oops -esr  2f665a0a379f::478cffed4b5f </code>
# <code>hg oops -esr  2f665a0a379f::478cffed4b5f </code>
# open the text editor to add the description of the backout, e.g.: “Backed out X changesets (bug 1359017) for <insert reason here> CLOSED TREE”.  
# open the text editor to add the description of the backout, e.g.: “Backed out X changesets (bug 1359017) for <insert reason here> CLOSED TREE”.  
# <code>hg push -r . inbound </code>
# <code>hg push -r . autoland </code>


= Best Practices and Communication =
= Best Practices and Communication =
Line 54: Line 54:
** Link to the push which got backed out, use a link which also shows classified failures. That way developers can check what platforms are affected and if there are more issues.
** Link to the push which got backed out, use a link which also shows classified failures. That way developers can check what platforms are affected and if there are more issues.
** Link to failure log of a failed log for easy access.
** Link to failure log of a failed log for easy access.
** Snippet of the failure message: This might provide insight if the developer can fix it quickly.
** Set the NEEDINFO flag in bugzilla. This is very important! Developers get a lot of bugmail and backout comments can be missed. Please make sure that you set a NEEDINFO to the developer in the bug when doing a backout. This is usually done by selecting "assignee" from the needinfo dropdown near the bottom.
** Set the NEEDINFO flag in bugzilla. This is very important! Developers get a lot of bugmail and backout comments can be missed. Please make sure that you set a NEEDINFO to the developer in the bug when doing a backout. This is usually done by selecting "assignee" from the needinfo dropdown near the bottom.
* Make sure that the failures that lead to the backout are [[Sheriffing/How:To:Treeherder#Classifying.2FStarring_jobs|starred in Treeherder]]. This helps the next sheriff on duty.
* Make sure that the failures that lead to the backout are [[Sheriffing/How:To:Treeherder#Classifying.2FStarring_jobs|starred in Treeherder]]. This helps the next sheriff on duty.
* First a change might be backed out for one issue but later a longer running task also fails due to those changes but maybe with a completely unrelated test. Update the backed out bug about this. Use a new comment, don't edit the previous backout comment because there is no bug mail for that.
* First a change might be backed out for one issue but later a longer running task also fails due to those changes but maybe with a completely unrelated test. Update the backed out bug about this. Use a new comment, don't edit the previous backout comment because there is no bug mail for that.
==Backouts from mozilla-central==
If a developer asks for a backout of patch which has already been merged to central, code sheriffs should ask them if the fix requires to ship a new Nightly as soon as possible. If yes, back it out from central, else request new Nightlies and merge back to autoland, else just back it out from autoland. This guides the developer better than the question if the backout should be done on autoland or central.


= How to test a backout on the Try server =
= How to test a backout on the Try server =
Line 76: Line 80:
'''Run hg histedit and replace pick with d.'''</li>
'''Run hg histedit and replace pick with d.'''</li>
</ol>
</ol>
= Rejected backout pushes =
By default, the server will reject changes to some folder or file types and a keyword needs to be part of the commit message to let it pass. This has also been used when the change landed (can also be in a different line of the commit message than the first one - in that case Treeherder won't show it) and is usually written in UPPERCASE.
Examples:
* <code>changesets contain changes to protected nsprpub/ directory</code>: Commit message requires <code>UPGRADE_NSPR_RELEASE</code>
* <code>changesets contain changes to protected security/nss/ directory</code>: Commit message requires <code>UPGRADE_NSS_RELEASE</code>


= Useful commands =
= Useful commands =
Line 85: Line 96:


<code>hg log -k "1234567"</code>
<code>hg log -k "1234567"</code>
= Backouts of bugless commits =
If the backed out commit has no bug number:
# Create a bug in which the failure and the backout is mentioned. Bugless commits should not be able to cause failures or bustage.
# Needinfo the person who pushed the failing change. If it was pushed by a bot, needinfo the triage owner of the modified files.
Confirmed users
611

edits