为新配置启用 Firefox 测试（手动）¶
您已准备好为新配置启用 Firefox 测试。到达此阶段后，您将看到一个尝试推送，其中所有测试都在运行（许多测试未通过），以验证某些测试是否通过，并且有足够的机器可用于运行测试。
出于本文档的目的，假设您的任务是将 Windows 10 操作系统从 1803 升级到 1903。为了简化起见，我们可以将其称为 windows_1903，我们需要
推送到 try
分析测试失败
禁用清单中的测试
重复尝试推送，直到没有失败
为测试失败提交错误
合并更改并启用测试
启用仅运行失败的测试
存在许多边缘情况，我将在每个步骤中概述它们。
推送到 Try 服务器¶
当您有新的机器（或云实例）可用于更新的操作系统/配置时，就可以推送到 try 了。
- 为了运行所有测试，我们需要执行
./mach try fuzzy --no-artifact -q 'test-windows !-raptor- !-talos- --rebuild 10
这里有一些例外情况
不需要运行性能测试（因此使用了
!-raptor- !-talos-）需要确保我们没有使用构件构建进行构建（因此使用了
--no-artifact）在第 3 层后面隐藏了一些作业，其中一些有充分的理由（代码覆盖率就是一个很好的例子，但裂变测试可能不会通过）
需要解决的最后一部分是在新配置上运行，以下是一些针对新配置的注意事项
重复的作业（例如，裂变、a11y-checks），您可以只运行这些特定任务：
./mach try fuzzy --no-artifact -q 'test-windows fission --rebuild 5新的操作系统/硬件（例如，aarch64、操作系统升级），您需要引用新硬件，通常使用
--worker-override：./mach try fuzzy --no-artifact -q 'test-windows --rebuild 10 --worker-override t-win10-64=gecko-t/t-win10-64-1903
这里的风险是硬件有限的情况，然后
--rebuild 10将创建过多的任务，并且某些任务将过期。在硬件资源不足的情况下，要么运行一部分测试（例如，web-platform-tests、mochitest），要么使用
--rebuild 3并重复。
分析测试失败¶
尝试推送需要几个小时，最好在开始工作时推送，这样结果将在您当天晚些时候准备好，或者在您下班时推送，结果将在您第二天上班时准备好。请确保在离开之前某些任务已开始，否则一个小小的打字错误可能会使此过程延迟数小时甚至整整一天。
查看测试失败的最佳方法是使用 Push Health 以避免误导性数据。Push Health 会将失败分成可能的回归、已知回归等。当查看 5 个数据点（来自 --rebuild 10）时，这将过滤掉间歇性故障。
您可能有无效或误导性数据的许多原因
# 测试间歇性地失败，我们需要一个模式来了解它是持续的还是间歇性的。# 我们仍然希望禁用高频间歇性测试，这些测试很烦人。# 您可能正在推送一个错误的基本修订版本（来自基本修订版本的回归或间歇性）。# 您运行的机器可能存在问题，导致数据出现偏差。# 基础设施问题可能导致作业在随机位置失败，重复的作业可以过滤掉这种情况。# 某些故障可能会影响同一浏览器会话或任务中的未来测试。# 如果发生崩溃，或者我们超时 - 我们可能无法运行任务中的所有测试，因此认为测试运行了 5 次，但也许它只运行了一次（并且失败了），或者根本没有运行。# 没有测试名称的任务失败（关闭时泄漏、关闭时崩溃、关闭时超时等）
这是不信任数据的许多原因，幸运的是，大多数情况下使用 --rebuild 10 将为我们提供足够的数据，使我们有足够的信心找到所有故障，并可以忽略随机/间歇性故障。
了解误导性数据的原因后，以下是如何使用 Push Health 的方法。
或者，您可以使用 API 获取原始数据并努力构建工具
如果您编写工具，则需要解析生成的 JSON 文件，并记住构建一个故障列表，并将其与作业名称列表匹配，以查找作业运行和通过/失败的次数。
这里的主要目标是知道哪些 <path>/<filenames> 失败，并拥有这些文件的列表。理想情况下，您会记录一些其他信息，例如超时、崩溃、失败等。最后，您可能会得到
dom/html/test/test_fullscreen-api.html, scrollbar
gfx/layers/apz/test/mochitest/test_group_hittest.html, scrollbar
image/test/mochitest/test_animSVGImage.html, timeout
browser/base/content/test/general/browser_restore_isAppTab.js, crashed
在清单文件中禁用测试¶
代码管理员一直在使用 此文档 进行培训和参考，以了解他们如何禁用间歇性问题。
首先，您需要添加一个关键字以便在清单中可用（例如，skip-if = windows_1903）。
存在许多例外情况，大部分工作将分为以下 4 个类别之一
# manifestparser: *.toml (mochitest*、firefox-ui、marionette、xpcshell) 通过添加
skip-if = windows_1903 # <comment>很容易编辑，这里有一些例外情况 # reftest: *.list (reftest、crashtest) 需要添加fuzzy-if(windows_1903, A, B)，这更具体 # web-platform-test: testing/web-platform/meta/**.ini (wpt、wpt-reftest 等) 需要编辑/添加 testing/web-platform/meta/<path>/<testname>.ini，并添加预期结果 # 其他（编译测试、jsreftest 等）编辑源代码，寻求帮助。
基本上，我们希望获取从 Push Health 中找到的每个非间歇性故障并编辑清单，这通常意味着
查找正确的清单。
在清单中添加正确的文本。
要查找正确的清单，它通常是 <path>/<harness>.[toml|list]。存在例外情况，如有疑问，请使用 searchfox.org/ 查找包含测试名称的清单。
获得清单后，在编辑器中打开它，并搜索确切的测试名称（可能存在名称相似的测试）。
重新运行 Try 推送，根据需要重复¶
测试您的更改非常重要，对于将要由管理员托管的新平台，需要大规模地重新运行所有测试。
在您的更改提交后，使用 --rebuild 10 再次推送到 try，并在第二天回来。
由于存在如此多的边缘情况，您很可能会遇到更多故障，在心理上计划 3 次迭代，每次迭代的故障都减少。
一旦您获得完整的推送以显示没有持续的故障，就可以合并这些更改并启用新的测试。这里存在很大的风险，即您花费的时间越长才能找到所有故障，则以下可能性越大
补丁文件腐烂
添加了新的测试，这些测试可能会在您的配置上失败
对测试/工具的其他编辑可能会影响您的新配置
由于新配置过程旨在快速查找故障并快速合并更改，因此我们无需请求开发人员进行审查，这将在新配置成功运行后进行，届时我们将通知团队哪些测试失败了。
为测试失败提交错误¶
一旦故障作业在 mozilla-central 上运行，我们现在就拥有了完整的覆盖范围，并且能够在 try 服务器上运行测试。可能会有 >100 个测试被标记为 skip-if，提交错误将花费大量时间。相反，我们将为每个编辑的清单提交一个错误，这通常会将错误数量减少到总测试的约 40%（平均每个清单 2.5 个测试失败）。
提交错误时，请说明时间线、如何运行失败、链接到我们创建配置的错误、简要描述配置更改（例如，将 Windows 10 从版本 1803 升级到 1903），最后需要通知分类所有者，表明这是一个提醒，并且这些测试将在接下来的 6-7 周内在 mozilla-central 上定期运行。
合并更改并启用测试¶
在您获得绿色测试运行后，就可以合并补丁了。可能需要对 taskgraph 进行更改，以便添加新的硬件类型并重复运行旧版和新版上的测试，或者创建新的变体并指示在该变体上运行哪些测试。
使用我们的 windows_1903 示例，这将是一种新的工作程序类型，需要进行以下编辑
transforms/tests.py（重复 Windows 10 条目）
test-platforms.py（复制 windows10 debug/opt/shippable/asan 条目并创建 win10_1903）
test-sets.py（理想情况下您不需要任何操作，否则复制
windows-tests并编辑测试列表）
通常，这应该允许您在 try 服务器上安排没有自定义标志的测试，并且所有这些测试默认情况下都将在 mozilla-central、autoland 和 release-branches 上安排。
启用仅运行失败的测试¶
现在我们已经定期运行测试，下一步是获取所有禁用的测试并在特殊的失败作业中运行它们。
我们已经创建了一个基本框架，但是对于每个测试工具（例如，xpcshell、mochitest-gpu、browser-chrome、devtools、web-platform-tests、crashtest 等），都需要创建一个相应的第 3 层作业。
待办事项：在我们的第一个作业运行后，指向如何添加此作业的示例。