为操作项依赖项强制实施锁文件

要求锁定文件可提供一致且可审核的保证，即每个工作流都运行经过审查的代码，而无需要求每个团队自行采用这种做法。有关简介，请参阅“工作流依赖项锁定文件”。

本指南可帮助你在所选存储库中运行试点，并设置自动化，使锁文件保持最新状态。当你确信锁文件按预期工作，并且不会给开发人员带来阻碍时，就可以强制实施 “要求锁文件” 策略。

Prerequisites

在强制实施工作流锁定文件并创建进程以使其保持最新之前，锁文件必须存在于存储库中。有关说明，请参阅“锁定存储库工作流中的 GitHub Actions 依赖项”。您无需是管理员即可创建锁文件。对存储库具有写入访问权限的任何人都可以执行此操作，因此可以在集中强制实施策略之前将接入流程委托给各个团队。

如果工作流从其他存储库调用可重用工作流，请确认这些源存储库也已完成接入。调用存储库的锁定文件未涵盖这些依赖项。如果被调用的可重用工作流未在其自己的存储库中接入，Require lockfile策略会阻止调用工作流的运行。

重要

策略的评估模式仅在 GitHub Enterprise Cloud 上可用。在确信已建立相应机制以确保所有目标工作流的锁文件保持最新状态之前，请勿在 Active 模式下启用此策略。

“需要锁文件”策略会阻止运行未纳入到存储库锁文件中的目标工作流，包括没有uses:依赖项的工作流。

在所有存储库中强制实施此策略之前，请先试运行。你应该：

需要锁定文件 是一项独立于 要求将操作固定为完整长度的提交 SHA 的策略。可以在发布期间同时启用这两项。若要配置策略并查看两者如何交互，请参阅管理GitHub Actions工作流的执行。

仅当锁文件保持最新时，强制执行才有效。添加自动化，以便开发人员无需记住每次创建或编辑工作流时都运行 lock 命令。

以下部分提供了有关如何在开发生命周期的不同点防止过时锁文件的示例：

当 Dependabot 提升某个操作的版本时，它会在同一拉取请求中重新生成匹配的锁文件条目。

除了由GitHub Actions管理Dependabot依赖项之外，不需要任何配置。请参阅“使用 Dependabot 保持操作的最新状态”。

Dependabot 不会支持尚未包含锁定文件条目的工作流，因此此选项会保留覆盖范围，而不是扩展它。

当某人添加或编辑工作流时，运行另一个运行 lock 命令的工作流。在对 .github/workflows/** 以及任何 action.yml 或 action.yaml 文件的更改时触发工作流，然后为其提供两个作业：

更新作业，用于在推送时重新生成锁文件并提交结果。此作业需要 contents: write 权限，分支保护规则或规则集必须允许 GitHub Actions 推送到该工作流运行的分支。写入 lockfile 需要 workflow OAuth 作用域，因此请确认工具具有该作用域。
在拉取请求上运行验证的gh actions-lock --verify作业。如果 lockfile 过时，则此操作应退出并显示错误，使其可用于必需检查。

有关现成的示例工作流，请参阅存储库中的 gh-actions-lock。如果你使用Copilot编辑工作流，还可以将其设置为在同一更改集中重新生成锁文件。请参阅 gh-actions-lock 技能和代理技能。

只有当有人查看差异时，锁文件才算是一种安全控制。具体来说，更改的提交 SHA 会告诉你工作流运行的代码已更改。

将.github/workflows/actions.lock添加到您的CODEOWNERS文件中，以便自动请求负责构建安全的团队进行评审。请参阅“关于代码所有者”。
配置分支保护规则或存储库规则集，以要求获得代码所有者批准。
告知审阅者要查找的内容。有关指导，请参阅“锁定存储库工作流中的 GitHub Actions 依赖项”。

如果确信锁定文件已就位，并且会保持最新状态，请将 “需要锁定文件” 策略的强制状态更改为 “活动”。确保所有载入的存储库和工作流都已设为目标对象。

重要

当 需要锁定文件 处于活动状态时，每个未载入其存储库锁定文件的目标工作流都会被阻止，即使同一存储库中的其他工作流已载入也是如此。在激活策略之前，请在每个目标存储库中运行gh actions-lock --verify，或在评估模式下查看策略见解，以确认涵盖每个目标工作流。

保留步骤 2 中的验证不变。策略阻止没有有效锁文件的工作流运行。相比之下，验证检查会在作者仍在处理拉取请求期间告知他们其锁定文件已过时。

如果验证检查失败，请参阅存储库中的 gh-actions-lock。