Puppeteer 供应商

如测试章节所述，我们在 try 上运行完整的Puppeteer 测试套件。这些测试在 central 的 remote/test/puppeteer/ 下进行供应商管理，我们有一个脚本可以引入上游更改。

我们定期执行手动双向同步。以下是流程概述，其中穿插了一些提示。

检查尚未上游的更改

在引入新的 Puppeteer 版本之前，请确保 mozilla-central 存储库中没有 Puppeteer 特定的更改尚未上游，这些更改自上次供应商操作以来一直存在。运行以下命令之一，并检查列出的错误或相关的上游代码以进行验证

% hg log remote/test/puppeteer
% git log remote/test/puppeteer

如果需要上游拉取请求，请参阅其contributing.md。通常，我们推送到 Puppeteer 的更改包括为 Firefox 取消跳过新通过的单元测试，以及对测试或 Firefox 特定的浏览器获取和启动代码进行少量修复。

请务必在 Puppeteer 存储库中针对 Chromium 和 Firefox 运行测试。您可以在执行此操作时指定您的本地 Firefox 构建

% BINARY=<path-to-objdir-binary> npm run test:firefox
% BINARY=<path-to-objdir-binary> npm run test:firefox:bidi

准备 Puppeteer 存储库

克隆 Puppeteer git 存储库并检出要引入 mozilla-central 的发行版标签。

% git checkout tags/puppeteer-%version%

您可能希望在此处安装项目，并确保单元测试通过。检查项目的package.json以获取相关的测试命令。

更新 mozilla-central 中的 Puppeteer 代码

您可以运行以下 mach 命令以复制您刚刚准备好的 Puppeteer 分支。mach 命令具有标志，可以指定本地或远程存储库以及提交

% ./mach remote vendor-puppeteer --commitish puppeteer-%version% [--repository %path%]

默认情况下，此命令还会安装新拉取的 Puppeteer 包，以便为我们的 CI 生成新的package-lock.json文件，用于固定 Puppeteer 依赖项。如果您想跳过此步骤，则可以使用--no-install选项；例如，如果您想稍后单独运行安装。

验证新创建的文件和文件夹是否需要由版本控制跟踪。如果不是，则针对这些路径更新顶级.hgignore和remote/.gitignore文件。

验证新代码是否有效

使用./mach puppeteer-test（请参阅测试）在无头模式下针对 Chromium 和 Firefox 运行 Puppeteer 测试。同样，仅针对 Firefox 运行部分测试是可以的——此时您只需要检查 typescript 是否编译以及浏览器二进制文件是否成功启动。

如果此阶段出现故障，您可能需要检查remote/test/puppeteer/package.json中的更改，并使用新的 npm 脚本更新remote/mach_commands.py。

验证期望元数据

接下来，您需要确保期望元数据正确。检查TestExpectations.json中的更改。如果 Firefox 有新跳过的测试，您可能需要更新这些期望。为此，请在 try 上运行 Puppeteer 测试作业（请参阅测试）。如果这些测试特定于 Chrome 或超时，我们希望保持跳过状态，如果它们失败，我们希望在期望元数据中为所有平台提供FAIL状态。您可以在日志文件末尾看到元数据是否需要更新。

检查作业日志，并确保运行没有因崩溃或挂起而过早中断，尤其是在 Treeherder 故障摘要中看到大量TEST-UNEXPECTED-MISSING时。您可能需要修复单元测试中的一些新错误。这是有趣的部分。

有些测试也可能意外通过。确保它是正确的，如果需要，请按照日志文件末尾的说明更新期望数据。

提交代码更改

一旦您对元数据感到满意并准备好提交同步补丁以供审查，请再次使用--rebuild 10在 try 上运行 Puppeteer 测试作业以检查稳定性。