GitHub Actions：工作流依赖锁定功能公开预览，标签引用与执行提交分离

同一标签执行不同代码的问题

Action 是工作流中负责特定任务的组件。使用其他仓库的 Action 时，其代码就成为工作流的依赖。如果只用标签或分支指定 Action 而不锁定，执行时就会选用该名称当时指向的代码。

标签就像书签，是可以移到其他位置的名称；提交则是标识某一时刻代码状态的记录。随着开发推进，分支指向的提交也会变化。即使工作流文件中的标签没有改变，提供方移动标签后，下次运行选中的提交也可能不同。

此前也可以直接在工作流文件中写入提交的完整标识符，固定执行对象。新功能提供了另一种方式：保留便于阅读的版本名称，将实际执行的提交写入单独的锁定记录。

保留名称，记录执行提交

根据 GitHub 文档，锁文件会同时记录标签或分支等引用名称，以及选定的提交。启用锁定后，即使引用名称后来指向其他代码，工作流仍会执行已记录的提交。

例如，某个标签最初指向提交 A，锁文件此时记录了 A。后来即使提供方将同一标签移到提交 B，启用锁定的工作流仍会执行 A。这是解释工作原理的假设示例，并非实际运行测试的结果。

锁定记录还包含所有者和仓库的数字标识符。GitHub Actions 会在执行时核对这些标识符，检查获取代码的仓库是否与锁定时为同一对象。这种方式不仅确认代码版本，也确认仓库身份。

锁定范围不仅包括直接调用的 Action，也包括该 Action 继续使用的依赖。工作流文件中直接列出的 Action 下游组件也会被记录，因此审核范围比表面可见的调用列表更广。

GitHub 说明，采用锁文件的仓库无需再在工作流文件中直接写入提交的完整标识符。这并不是取消对执行对象的固定，而是将固定位置从工作流文件移到锁文件。

仓库边界与安全性、可复现性的限制

可复用工作流是一组可供其他工作流调用的任务流程。如果它位于其他仓库，其内部依赖由定义该工作流的仓库中的锁文件负责。调用方的一份文件无法锁定对方仓库内部的依赖，因此对方仓库也需要启用锁定。

被锁定的提交必须存在于源仓库的某个分支中。锁文件会记录提交，并不意味着任何提交都能不受所在位置限制而持续执行。

GitHub 明确说明，锁定不会判断依赖本身是否安全。即使固定了执行代码，代码中的恶意行为或漏洞仍需单独审核。本文依据公告与文档进行说明，并非独立运行测试或安全改进测量的结果。

文档所强调的可复现性，也需要限定在依赖提交的选择范围内理解。选择同一提交，只是固定了构建所用的一项材料，并不保证整个结果相同。没有依据表明该功能还能让运行环境、下载的软件包和外部服务保持一致。

适用套餐与启用时的变更核对

公告列明的适用套餐包括 Enterprise Cloud、启用数据驻留（指定数据存储区域）的 Enterprise Cloud、Team 和 Free。

团队可以逐个选择工作流，也可以批量将其纳入锁定范围。选择工作流是在确定适用范围，为各个 Action 依赖生成锁定条目则是在记录这一范围。扩展会生成锁文件和工作流变更，团队需确认选定工作流的所有 Action 依赖都有对应条目，并将两类变更一并审核和提交。

需要检查的文件是 .github/workflows/actions.lock，生成和维护使用 GitHub CLI 的 gh actions-lock 扩展。文档建议不要手动编辑该文件。记录中的 ref 是标签或分支等引用名称，commit 是提交，owner_id 和 repo_id 分别是所有者与仓库的数字标识符。前文所说的提交完整标识符指的是 SHA。

审核时，除了标签名称，还需查看记录中的提交变化。如果标签保持不变，但锁定记录从 A 改为 B，执行对象就发生了变化。关键不只是生成文件，而是确认选定的工作流与生成的依赖条目相符。