Gutenberg 发起 wp/X.Y 分支 GitHub Actions 工作流修复代码审查

虽然唯一 actively supported 的 WordPress 版本是最新版本，但出于 courtesy，安全更新也会回移植到较旧的分支。所有版本的 >=4.7 都处于仅提供安全支持的阶段，作为对 WordPress 用户的 courtesy，它们会收到部分安全补丁。

Gutenberg 仓库中维护的代码对于所有 WordPress 版本 >=5.0 都同样至关重要。

Gutenberg 仓库中与每个 WordPress 版本对应的代码使用 wp/X.Y 分支进行组织。这些分支是代码在时间上的冻结快照，wordpress-develop 使用这些代码构建了最终向全球发布的软件。然而，由于这些分支中的测试基础设施没有得到良好维护，自动检查和测试套件目前已无法正常工作。有些始终失败，另一些则因分支筛选范围不准确、事件目标设置不当及其他问题而完全无法运行。

必须让这些 GitHub Actions 工作流及其底层测试基础设施恢复到可正常工作的状态，以确保所有影响 Gutenberg 的相关安全补丁在随 WordPress 核心交付给最终用户之前，都能得到适当验证和确认。

这就是你的作用！

参与：Operation Tall Stack

过去几周，我与 AI 合作，为 gutenberg 仓库中的每一个 wp/x.y 分支创建了一组堆叠式拉取请求，使其能够：

再次让 CI 通过，以便对这些分支的更改进行适当测试，然后随 WordPress 版本发布。
通过移除在发布分支上没有用途的任务、更新并固定 actions 和 runner 镜像，以及加入作业超时和工作流 lint 等安全措施，使工作流实现现代化并强化安全。
将每个分支的测试环境固定到与其 WordPress 版本相匹配的软件版本，并测试该版本实际支持的 PHP 和 Node.js 版本，从而使各分支的测试环境可预测。
修复本地开发工具（wp-env、Composer 和 PHPUnit），这些工具因其所依赖的外部服务和软件包随时间发生变化而失效。
通过修复问题或回移植修复，让测试套件恢复稳定，解决不稳定的测试和已损坏的测试。

有关实现方法的一些细节：

每个 PR 只做一项修复。 每个堆叠包含 18 到 32 个拉取请求，每个请求都处理一个具体问题。审查以小而精准的片段进行，而不是一次性审查一个庞大的差异。
堆叠式 PR。 每个 PR 都基于其下方的一个 PR，因此整个堆叠需要自下而上阅读。每个 PR 的 Files changed 标签页只显示该 PR 的更改，而最上方 PR 的 CI 会同时测试整个堆叠。
相同修复，在每个分支上采用相同形式。 适用于多个分支的修复在每个分支上都有相同的分支名称（fix-actions-X.Y/<fix-name>）和匹配的标题。它在每个堆叠中的位置也大致相同。这样就可以一次性审查所有分支上的同一项修复，而不必通读某个分支的整个堆叠。
只处理确有需要的分支。 每项修复都会根据每个分支的实际代码进行检查，只有存在问题的分支才会出现该修复。如果分支之间存在差异，PR 会针对该分支调整修复方案。
尽可能遵循 trunk 。许多修复都是对 trunk 上已有更改的回移植或改编，这些 PR 会链接到原始 PR 或提交。
没有新的软件包发布：禁止进行任何会发布该存储库 npm 软件包新版本的操作。唯一的例外是 wp-env，这是一个仅供开发使用的工具，不属于交付给用户的 WordPress 代码，且大量测试基础设施的正常运行都依赖于它。
有文档记录且可追踪。每个 PR 描述都会说明改了什么、为什么改以及如何改，并引用其所解决的失败 CI 运行记录或错误输出。每个 PR 还会链接到其分支对应的跟踪 issue。
人工审查：与这项工作相关的任何处于草稿状态的拉取请求，都应视为由 AI 生成且尚未经人工验证。我已将每个分支的一组堆叠分支暂存到我的 fork 中，以便在推送到 WordPress/gutenberg 前进行测试和验证。每个 PR 都会在最终确认后标记为可供审查。

审查策略

在这项工作合并之前，需要对其进行审查和批准。考虑到 20 多个分支中总计约有 500 个拉取请求，需要你的协助。

在与几位贡献者讨论后，显然，要妥善审查每个分支的一组拉取请求，最佳方式是按修复项划分，而不是按各个堆叠分支划分。这样，审查者便能审查与特定修复相关的所有 PR，而无需在每个堆叠分支中的每一个问题之间来回切换，同时结合 wp/X.Y 各分支中的代码进行考量。

虽然该项目有一个总 ticket（GB-82780），且每个 wp/X.Y 分支都有一个子 issue，但各项单独修复没有对应的 issue。为帮助划分和跟踪审查工作且避免重叠，我创建了一个用于认领和跟踪审查工作的 issue（GB-84853）。

你可以在该 issue 中找到一张表格，为每项修复分配字母标识符，并链接到各版本分支对应的拉取请求。第一条评论会列出分支名称、1 至 2 句说明，以及将相同更改应用到 trunk 的所有 PR（如果有）。

如果你有能力且有兴趣协助审查这些拉取请求，请遵循以下流程：

在 GB-84853 下留言，认领某项修复。
如果可以，请编辑 issue 描述中的表格，将自己添加为该项修复的审查者。
当你认领某项修复时，即表示你承诺会对该行中的每个 PR 明确提交批准审查或请求更改的审查。某个堆叠分支中的每个 PR 都必须获得批准审查，否则无法合并该堆叠分支。
每次只认领一行。完成第一项后，你随时可以再认领其他项。
如果你正在审查某一行中的 PR，但无法在 24 小时内完成，请在 issue 中留言（如果可以），并在表格的 Reviewer 一列中注明你审查过的分支。示例：“Needed: 6.0-5.7. (@desrosj reviewed 7.1-6.1)”

任何人都可以协助审查这些 PR。不过，gutenberg 存储库中配置的规则集要求，至少有一位获得该存储库写入权限的 WordPress GitHub 组织成员提交批准审查。

目前只有 wp/7.1 到 wp/5.7 分支已准备就绪并推送到 gutenberg 存储库，其余分支将在未来几天内添加。新的堆叠分支推送并准备就绪后，会在该 issue 中留言通知所有协助者。

阶段 2

将这些工作流恢复到可用状态，是为使其长期更易维护所需工作的第一阶段。一旦各个 wp/X.Y 分支中的工作流恢复可用，第二阶段工作将开始采用与 wordpress-develop 中策略相匹配的可复用工作流模式（见 Trac #61213）；这会显著简化这些工作流文件的维护，因为执行的功能逻辑位于主干中，并由所有执行特定类型测试或自动化的分支共享。

预先感谢每一位为这项工作提供帮助的人！

感谢 @johnbillion、@jorbin、@lancewillett 在发布前进行审阅。

#build-test-tools