配置更改¶
此流程概述了 Mozilla 如何处理配置更改。有关配置更改的列表，请参阅计划
基础设施设置 (2-4 周)¶
这是幕后工作，当需要进行配置更改（升级或添加新平台）时，第一步是构建一台机器并努力使操作系统与 taskcluster 协同工作。硬件/云方面的工作由 IT 完成。有时这与在现有机器上安装软件包或更改操作系统设置一样简单，但这需要自动化和文档记录。
在某些情况下，几乎无需任何工作，因为 CI 更改是在使用不同的运行时设置（环境变量或首选项）运行测试。
在 try 服务器上设置池 (1 周)¶
下一步是在 try 服务器上获得一些可用的机器。在这里，我们在树中添加一些代码以支持新配置（新的工作程序类型、测试变体等），并验证 IT 完成的任何设置是否与 taskcluster 客户端协同工作。然后 Releng 确保目标测试可以在基本级别运行（mozharness、testharness、操作系统环境、日志记录、某些内容通过）。
使测试变为绿色 (1 周)¶
在此阶段，Releng 将在 try 服务器上运行所有目标测试，并禁用、跳过或失败所有未通过或频繁间歇性出现的测试。通常情况下，会有十几次这样的迭代，因为一项测试中的崩溃意味着我们不会运行清单中的其余测试。
将新配置打开为第二层 (1/2 周)¶
我们将在新版本开始时安排此操作。
Releng 将为所有未通过的测试更改清单，然后默认安排新作业。这将是第二层，原因有几个
这是一个新的配置，其中许多测试仍然需要关注
在许多情况下，还有一个以前的配置（例如，将 Windows 10 从 1803 升级到 1903），它仍在作为第一层并行运行
这现在将在中心和集成中运行，并在 try 服务器上可用。在机器有限的少数情况下（Android 手机），将需要关闭旧配置，或使 try 服务器访问隐藏在./mach try --full后面
打开运行已跳过测试的新后备作业 (1/2 周)¶
Releng 将打开一个新的临时作业，该作业将运行默认情况下未变为绿色的测试。这些将在 mozilla-central 上作为第二层运行，并由负责人管理。
这里的目标是查找现在已通过并应默认运行的测试。通过这样做，我们实际上是在运行所有测试，而不是禁用数十个测试并忘记它们。
移交给开发者 (1 周)¶
Releng 将为所有失败的测试提交 Bug（每个清单一个 Bug），并需要信息告知分类所有者，以提高他们所在区域的一个或多个测试需要关注的认识。此时，Releng 已完成工作，并将继续其他工作。开发人员可以在 try 服务器上重现故障，并在修复后根据需要编辑清单。
在将它们提升到第一层之前，至少有 6 周的时间来调查和修复测试。
将配置移动到第一层 (6-7 周后)¶
在配置作为第二层运行并进入 Beta 版以及发布分支后（即 2 个新版本之后），Releng 将
关闭旧的第一层测试（如果适用）
将第二层作业提升到第一层
关闭后备作业
这允许开发人员在 6 周的时间内安排时间来调查和修复任何测试故障。