Sheriffing/Deciding To Close A Tree: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
(infra failure example from philor) |
||
| Line 1: | Line 1: | ||
== Deciding to close a tree == | |||
=Deciding to close a tree | |||
Many objective and subjective criteria are part of deciding to close a tree. Tree closure means that developers are prevented from pushing or merging code to a codebase. Later, sheriffs will reopen the trees when the problem appears to be resolved. | Many objective and subjective criteria are part of deciding to close a tree. Tree closure means that developers are prevented from pushing or merging code to a codebase. Later, sheriffs will reopen the trees when the problem appears to be resolved. | ||
| Line 9: | Line 8: | ||
* Infrastructure or systems failures that affect a significant number of tests or builds (e.g. AWS, data center, networking issues) | * Infrastructure or systems failures that affect a significant number of tests or builds (e.g. AWS, data center, networking issues) | ||
* Mass "bustage" that could hide other test failures (this is when code lands and causes multiple tests to fail across multiple chunks of tests or suites of tests, making it harder to catch further failures if something else lands *during* the period in which these tests are failing from the original code landing) | * Mass "bustage" that could hide other test failures (this is when code lands and causes multiple tests to fail across multiple chunks of tests or suites of tests, making it harder to catch further failures if something else lands *during* the period in which these tests are failing from the original code landing) | ||
* Infra failure that affects our ability to see what's happening (e.g. treeherder being down or not ingesting jobs or the data it consumes not being updated, or treestatus being broken so we're closed by default) | |||
Revision as of 19:25, 24 May 2016
Deciding to close a tree
Many objective and subjective criteria are part of deciding to close a tree. Tree closure means that developers are prevented from pushing or merging code to a codebase. Later, sheriffs will reopen the trees when the problem appears to be resolved.
Some of the criteria used include:
- Broken build on an integration or main tree (e.g. mozilla-inbound, mozilla-central, fxteam)
- Excessive backlog for builds or tests in any platform
- Infrastructure or systems failures that affect a significant number of tests or builds (e.g. AWS, data center, networking issues)
- Mass "bustage" that could hide other test failures (this is when code lands and causes multiple tests to fail across multiple chunks of tests or suites of tests, making it harder to catch further failures if something else lands *during* the period in which these tests are failing from the original code landing)
- Infra failure that affects our ability to see what's happening (e.g. treeherder being down or not ingesting jobs or the data it consumes not being updated, or treestatus being broken so we're closed by default)