MozillaWiki

Sheriffing/Job Visibility Policy: Difference between revisions

Page Discussion

Sheriffing/Job Visibility Policy (view source)

Revision as of 08:32, 21 November 2022

1,089 bytes removed ,  21 November 2022
→‎Has sufficient documentation: Updated automated testing link to a Firefox source docs page
(Split requirements into those for all jobs vs those for tier 1 jobs)
(→‎Has sufficient documentation: Updated automated testing link to a Firefox source docs page)
 
(17 intermediate revisions by 6 users not shown)
Line 1: Line 1:
This page exists to clarify the policy towards how jobs reporting to [https://treeherder.mozilla.org/ Treeherder] are managed. Common sense will apply in cases where some of the requirements are not applicable for a particular platform/build/test type.


== Requirements for jobs shown in the default Treeherder view ==
To propose changes to this policy, please speak to the sheriffs and/or send a message to the [https://groups.google.com/a/mozilla.org/g/sheriffs sheriffs group].


This page was created to clarify the requirements that a platform/test-suite has to meet, before its jobs can be shown in the default [https://tbpl.mozilla.org/ TBPL] view for the main development trees. Owners of non-sheriff managed project/disposable repos do not need to meet these requirements before requesting visibility changes.  
== Overview of the Job Visibility Tiers ==
Jobs reporting to Treeherder can fall into three tiers.
* <b>Tier 1:</b> Jobs that run on a [https://firefox-source-docs.mozilla.org/build/buildsystem/supported-configurations.html Tier-1 platform], are shown by default on Treeherder, and are sheriff-managed. Bustage will cause a tree closure and is expected to result in a quick follow-up push or a backout (at the discretion of the sheriff on duty). Bugs will be filed for new intermittent test failures and are subject to the [https://wiki.mozilla.org/Sheriffing/Test_Disabling_Policy Test Disabling Policy] if not addressed in a timely fashion.
* <b>Tier 2:</b> Jobs are shown by default on Treeherder and sheriffs will create bugs for new failures, even if those are permanent. New test failures/bustage will not result in a backout, but a tracking bug will be filed when observed. These new issues are expected to be fixed in 2 business days.
* <b>Tier 3:</b> Jobs are not shown by default on Treeherder. All responsibilities for monitoring the results will fall upon the owner of the job.


Common sense will apply in cases where some of the requirements are not applicable for a particular platform/build/test type.
== Requirements for jobs shown in the default Treeherder view ==
 
The below section applies to <b>both Tier 1 and Tier 2 jobs</b>. Owners of non-sheriff managed project/disposable repos do not need to meet these requirements. However, they must be satisfied prior to being enabled in production.
To propose changes to this policy, please speak to the sheriffs and/or post to [https://lists.mozilla.org/listinfo/dev-platform dev.platform].


==== Has an active owner ====
==== Has an active owner ====
* Who is committed to ensuring the other requirements are met not just initially, but over the long term.
* Who is committed to ensuring the other requirements are met not just initially, but over the long term.
* Who will ensure the new job type is switched off to save resources, should we stop finding it useful in the future.
* Who will ensure the new job type is switched off to save resources should we stop finding it useful in the future.


==== Outputs failures in a TBPL-starrable format ====
==== Usable job logs ====
* It is highly recommended that new test harnesses do not reinvent the wheel and instead use parts of [https://wiki.mozilla.org/Auto-tools/Projects/MozBase mozbase] (eg: mozcrash) if at all possible - speak to the [[Auto-tools|A-Team]] for more info.
* Full logs should be available for both successful and failed runs in either raw or structured formats.
* Failures must appear in the TBPL annotated summary (ie: matches the [https://hg.mozilla.org/webtools/tbpl/file/tip/php/inc/GeneralErrorFilter.php log parsing regexp]), otherwise the full log will have to be opened for every failure.
* The crash reporter should be enabled, mini-dumps processed correctly (ie: with symbols available) & the resultant valid crash stack visible in the log (it is recommended to use mozcrash to avoid reinventing the wheel).
* Failure output must be in the format expected by TBPL's [https://hg.mozilla.org/webtools/tbpl/file/tip/php/inc/AnnotatedSummaryGenerator.php bug suggestion generator] (otherwise sheriffs have to manually search Bugzilla when starring intermittent failures):
* Failures must appear in the Treeherder failure summary in order to avoid having to open the full log for every failure.
* Failure output must be in the format expected by the Treeherder's [https://github.com/mozilla/treeherder-service/blob/master/treeherder/model/error_summary.py bug suggestion generator] (otherwise sheriffs have to manually search Bugzilla when classifying/annotation intermittent failures):
** For in-tree/product issues (eg: test failures, crashes):
** For in-tree/product issues (eg: test failures, crashes):
*** Delimeter: ' | '
*** Delimeter: ' | '
Line 22: Line 27:
*** 3rd token: The specific failure message (eg: the test part that failed, the top frame of a crash or the leaked objects list for a leak).
*** 3rd token: The specific failure message (eg: the test part that failed, the top frame of a crash or the leaked objects list for a leak).
** For non test-specific issues (eg: infra/automation/harness):
** For non test-specific issues (eg: infra/automation/harness):
*** TBPL falls back to searching Bugzilla for the entire failure line (excluding mozharness logging prefix), so it should be both unique to that failure type & repeatable (ie: no use of process IDs or timestamps, for which there will rarely be a repeat match against a bug summary).
*** Treeherder falls back to searching Bugzilla for the entire failure line (excluding mozharness logging prefix), so it should be both unique to that failure type & repeatable (ie: no use of process IDs or timestamps, for which there will rarely be a repeat match against a bug summary).
** Exceptions & timeouts must be handled with appropriate log output (eg: the failure line must state in which test the timeout occurred, not just that the entire run has timed out).
** Exceptions & timeouts must be handled with appropriate log output (eg: the failure line must state in which test the timeout occurred, not just that the entire run has timed out).
** [documentation for mozlog library https://firefox-source-docs.mozilla.org/mozbase/mozlog.html]
* The sheriffs will be happy to advise regarding the above.
* The sheriffs will be happy to advise regarding the above.
==== Low intermittent failure rate ====
* A high failure rate:
** Causes unnecessary sheriff workload.
** Affects the ability to sheriff the trees as a whole, particularly during times of heavy coalescing.
** Undermines devs confidence in the platform/test-suite - which as demonstrated by Firefox for Android, permanently affects their willingness to believe any future failures, even once the intermittent-failure rate is lowered.
* A mozilla-central push results in ~400 jobs. The typical OrangeFactor across all trunk trees is normally (excluding the recent spike) 3-4, ie: a failure rate of ~1%.
* Therefore as a rough guide a new platform/testsuite must have at most a 5% per job failure rate initially, and ideally <1% longer term.
* However, sheriffs will make the final determination of whether a job type has too many intermittent failures. This will be a based on a combination of factors including failure rate, length of time the failures have been occurring, owner interest in fixing them & whether TBPL is able to make bug suggestions.
==== Must avoid patterns known to cause non deterministic failures ====
* Must avoid pulling the tip of external repositories as part of the build - since landings there can cause non-obvious failures. If an external repository is absolutely necessary, instead reference the desired changeset from a manifest in mozilla-central (like talos or gaia do).
* Must not rely on resources outside of the build network:
** Since these will cause failures when the external site is unavailable, as well as impacting end to end times & adding noise to performance tests.
** eg: Emulator/driver binaries direct from a vendor's site, package downloads from PyPi or page assets for unit/performance tests.
** Ensure MOZ_DISABLE_NONLOCAL_CONNECTIONS is defined in the automation environment (see {{bug|995417}}) & use a list of automation prefs for switching off undesirable behaviour (eg automatic updates, telemetry pings; see {{bug|1023483}} for where these are set).
* Must not contain time bombs, e.g. tests that will fail after a certain date or when run at certain times (e.g., the day summer time starts or ends, or when the test starts before midnight and finishes after midnight).
* See the [https://developer.mozilla.org/en-US/docs/Mozilla/QA/Avoiding_intermittent_oranges best practices for avoiding intermittent failures (oranges)].


==== Has sufficient documentation ====
==== Has sufficient documentation ====
Line 51: Line 39:
** The current owner/who to contact for help.
** The current owner/who to contact for help.
** The Bugzilla product/component where bugs should be filed (Github issues is not discoverable enough and prevents the use of bug dependencies within the rest of the project).
** The Bugzilla product/component where bugs should be filed (Github issues is not discoverable enough and prevents the use of bug dependencies within the rest of the project).
* That wiki page is linked to from https://developer.mozilla.org/docs/Mozilla/QA/Automated_testing
* That wiki page is linked to from https://firefox-source-docs.mozilla.org/testing/automated-testing/index.html
 
==== Crashes should produce valid crash stacks ====
* The crash reporter should be enabled, mini-dumps processed correctly (ie: with symbols available) & the resultant crash stack output in the job log.
 
==== Logs should not exceed the max log size ====
* Logs for both successful and failed runs should not exceed the log size limit, which in the case of buildbot is 50MB for all buildsteps including those outside of mozharness.
 
== Additional requirements for tier 1 jobs ==


Tier 1 jobs are those that ... #todo (also reference https://developer.mozilla.org/en-US/docs/Supported_build_configurations). In addition to the requirements above, tier 1 jobs must also meet the following.
== Additional requirements for Tier 1 jobs ==


==== Breakage is expected to be followed by tree closure or backout ====
==== Breakage is expected to be followed by tree closure or backout ====
* Failures visible in the default view (other than those that are known intermittents/transient), must have their cause backed out in a timely fashion or else the tree closed until diagnosed.
* Failures visible in the default view (other than those that are known intermittents/transient), must have their cause backed out in a timely fashion or else the tree closed until diagnosed.
* Why? If tier != 1 jobs were instead made visible in the default view, they would:
* Sheriffs will generally ping in [https://chat.mozilla.org/#/room/#developers:mozilla.org #developers on chat.mozilla.org] when such a situation arises. If sufficient time passes without acknowledgement (typically ~5min), the regressing patch(es) will be backed out in order to minimize the length of the closure for other developers.
** Interfere with ability to sheriff the tree:
* If acknowledged, sheriffs will decide in conjunction with the developer whether backing out or fixing in-place is the most reasonable resolution. The sheriff maintains the right to backout if necessary, however.
*** Indistinguishable from tier-1 failures.
*** Appear in the failure count/cause the tab to glow.
*** Slow down navigation of failures when using keyboard shortcuts.
** Cause extra workload for sheriffs by making them perform initial diagnosis/bug filing & then starring of the failure on every push until it is fixed an indeterminate amount of time later.
** Cause confusion for non-sheriffs using project branches/try-server, as well as on all trees at the weekends when there are no employed sheriffs.
* If your platform/test falls under the category of "someone should just file a bug and it will be investigated by our team later", then it unfortunately does not meet this requirement. From past requests this normally translates to "group X think this job type is important but we want to delegate the task of monitoring it to someone else".


==== Runs on mozilla-central and all trees that merge into it ====
==== Runs on mozilla-central and autoland ====
* Otherwise job failures when tree X merges into mozilla-central will not be attributable to a single changeset, resulting in either tree closure or backout of the entire merge (see requirement #2).
* Necessary because job failures when autoland merges into mozilla-central will not be attributable to a single changeset, resulting in either tree closure or backout of the entire merge (see the previous requirement).
* When filing the release engineering bug to enable your job on all the required trees, ask to enable it on "mozilla-central based trees" and release engineering will enable it in the default config from which all trunk trees inherit (unless the various tree owners have explicitly opted out). As a rough guide, mozilla-central based trees include mozilla-inbound, fx-team, b2g-inbound as well as many of the other project/disposable repositories.


==== Scheduled on every push ====
==== Scheduled on every push ====
* Otherwise job failures will not be attributable to a single changeset, resulting in either tree closure or backout of multiple pushes (see requirement #2).
* Otherwise job failures will not be attributable to a single changeset, resulting in either tree closure or backout of multiple pushes (see requirement #2).
* An exception is made for nightly builds with an virtually equivalent non-nightly variant that is built on every push & for tests run on PGO builds (given that PGO builds take an inordinate amount of time, we still schedule them every 3/6 hours depending on tree, and relatively speaking there are not too many PGO-only test failures).
* An exception is made for nightly builds with a virtually equivalent non-nightly variant that is built on every push & for tests run on shippable builds (relatively speaking there are not too many shippable-only test failures). Periodic builds have also been granted an exception as they don't run tests and have sufficient coverage on other platforms such that the odds of unique bustage are small and relatively easy to diagnose.
* Note also that coalescing (buildbot queue collapsing when there is more than one queued job of the exact same tree/type) may mean that not all scheduled jobs actually get run. Whilst coalescing makes sheriffing harder, it's a necessary evil given that automation infrastructure demand frequently outstrips supply.
* Note also that scheduling optimization (may mean that not all scheduled jobs actually get run. Whilst such coalescing makes sheriffing harder, it's a necessary action to keep the automation infrastructure demand at reasonable levels.
 
==== Must avoid patterns known to cause non deterministic failures ====
* Must avoid pulling the tip of external repositories or their latest release as part of the build - since landings there can cause non-obvious failures. If an external repository/dependency is absolutely necessary, instead reference the desired changeset or version from a manifest in mozilla-central.
* Must not rely on resources from sites whose content we do not control/have no SLA:
** Since these will cause failures when the external site is unavailable, as well as impacting end to end times & adding noise to performance tests.
** eg: Emulator/driver binaries direct from a vendor's site, package downloads from PyPi or page assets for unit/performance tests.
** Ensure MOZ_DISABLE_NONLOCAL_CONNECTIONS is defined in the automation environment (see {{bug|995417}}) & use a list of automation prefs for switching off undesirable behavior (e.g. automatic updates, telemetry pings; see {{bug|1023483}} for where these are set).
* Must not contain time bombs, e.g. tests that will fail after a certain date or when run at certain times (e.g., the day summer time starts or ends, or when the test starts before midnight and finishes after midnight).
* See the [https://developer.mozilla.org/en-US/docs/Mozilla/QA/Avoiding_intermittent_oranges best practices for avoiding intermittent failures (oranges)].
 
==== Low intermittent failure rate ====
* A high failure rate:
** Causes unnecessary sheriff workload.
** Affects the ability to sheriff the trees as a whole, particularly during times of heavy coalescing.
** Undermines confidence in the platform/test-suite - which permanently affects developers' willingness to believe any future failures, even once the intermittent-failure rate is lowered.
* A mozilla-central push results in 4000-10000 jobs. The typical intermittent failure rate (OrangeFactor) across all trunk trees is normally 2-4%.
* Therefore as a rough guide a new platform/test suite must have at most a 5% per job failure rate initially, and ideally <1% longer term.
* However, sheriffs will make the final determination of whether a job type has too many intermittent failures. This will be a based on a combination of factors including failure rate, length of time the failures have been occurring, owner interest in fixing them & whether Treeherder is able to make bug suggestions.


==== Easily run on try server ====
==== Easily run on try server ====
* Otherwise developers who have had their landing backed out for breaking the job type may be unable to debug the failures/test the fix, particularly if they only reproduce on our infrastructure.
* Needed so that developers who have had their landing backed out for breaking the job type are able to debug the failures/test the fix, particularly if they only reproduce on our infrastructure.
* Developers should not be expected to guess try chooser options, so http://trychooser.pub.build.mozilla.org/ should be updated if appropriate.
* The job should be visible to |./mach try fuzzy| and |./mach try chooser| without having to use the --full option.


== Optional, but helpful ==
== Optional, but helpful ==
Line 91: Line 82:
==== Easy for a dev to run locally ====
==== Easy for a dev to run locally ====
* Supported by mach (if appropriate).
* Supported by mach (if appropriate).
* Ideally part of mozilla-central (legacy exceptions being Talos, gaia).
* Ideally part of mozilla-central (legacy exceptions being Talos).


==== Supports the disabling of individual tests ====
==== Supports the disabling of individual tests ====
* It must be possible for sheriffs to disable an individual test per platform or entirely, by either annotating the test or editing a manifest/moz.build/Makefile in the relevant gecko repository.
* It must be possible for sheriffs to disable an individual test per platform or entirely, by either annotating the test or editing a manifest in the relevant gecko repository.


== Requesting changes in visibility ==
== Requesting changes in visibility ==
* Please file a bug using this [https://bugzilla.mozilla.org/enter_bug.cgi?cc=sheriffs%40mozilla.bugs&comment=Job%2Fplatform%20ZZZZZZ%20now%20meets%20the%20requirements%20at%3A%0D%0Ahttps%3A%2F%2Fwiki.mozilla.org%2FSheriffing%2FJob_Visibility_Policy%0D%0A%0D%0APlease%20may%20it%20be%20unhidden&component=Tinderboxpushlog&form_name=enter_bug&op_sys=All&product=Webtools&rep_platform=All&short_desc=Please%20unhide%20job%2Fplatform%20ZZZZZZ%20on%20TBPL&version=Trunk template], so that changes in visibility are more discoverable (vs IRC or asking as part of a bug in another product/component) and reasoning/history is preserved.
* Jobs that are marked as tier 3 will be hidden in Treeherder by default.
* To adjust the tier for a Taskcluster job, use a bug either in the Firefox Build System :: Task Configuration component, or else a component related to the type of task being adjusted, then edit the in-tree task definition.
* CC :sheriffs when adjusting a job's tier, so they are aware of the change and can confirm the criteria have been met.


== My platform/test-suite does not meet the requirements, what now? ==
== Adding a new test task or a new test platform? ==
* Your platform/test-suite will still be being run, just not shown on the default view. This model has worked well for many projects/build types (eg jetpack, xulrunner, spidermonkey).
* Be sure to demonstrate an acceptable intermittent failure rate for your new test tasks on try, and include the try links in the bug which adds the new tasks. Usually that means repeating each new test task at least 10 times (try: --rebuild 10).  
* To see it, append '&showall=1' to the URL ({{bug|748833}} will add a checkbox for this to the TBPL UI).
* For each known intermittent failure, check the expected frequency from recent comments in the bug, or by looking up the failure in Treeherder's Intermittent Failures view; if you see higher failure rates in your try push, consider fixing or disabling the test(s) before enabling your new task(s).
* To filter the jobs displayed, under the 'Filters' menu use the 'job name' field (which supports regexp).
* eg: to see both ASan & Valgrind jobs on mozilla-central (neither of which are shown by default), use: [https://tbpl.mozilla.org/?showall=1&jobname=(asan|valgrind) https://tbpl.mozilla.org/?showall=1&jobname=(asan|valgrind)]
* For Try specifically, you can request that the job type by made non-default (ie requires explicit opt-in when using trychooser syntax, and won't be scheduled with '-u all' or similar), in order to be shown in the default view on Try - [http://hg.mozilla.org/build/buildbot-configs/file/27dff21cb799/mozilla/config.py#l332 example].


== The future ==
== My platform/test-suite does not meet the base requirements, what now? ==
* Planned improvements to our tooling will likely mean that some of these requirements can be relaxed in the future, as well as making it easier for maintainers of non-default-view job types to track their success/failure without having to monitor TBPL continuously.
* Your platform/test-suite will still be being run, just not shown on the default view. This model has worked well for many projects/build types (e.g. spidermonkey).
* Planned features for the successor to TBPL ([[Auto-tools/Projects/Treeherder]]) include:
* To see it, click the "3" button to the left of the quick filter input field in the second toolbar of the Treeherder UI.
** Multiple dashboards/views for different use-cases/teams (giving us more flexibility than just "default view" or "&showall=1").
* To filter the jobs displayed, under the 'Filters' menu use the 'job name' field.
** Opt-in notifications (email, IRC, dashboard, ...?) of failures for desired job types (see proposal in {{bug|851061}}).
* For Try specifically, you can request that the job type be made non-default (i.e. requires explicit opt-in when the tasks to run get selected), in order to be shown in the default view on Try - see <code >UNCOMMON_TRY_TASK_LABELS</code> in [taskcluster/taskgraph/target_tasks.py target_tasks.py].
* [[Auto-tools/Projects/Bisect_in_the_cloud]] will allow sheriffs to more easily narrow regression ranges for job types that do not run on every push, making it more viable to accept them into certain views/dashboards.
Standard8
canmove, Confirmed users, Bureaucrats and Sysops emeriti
3,627

edits

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