GitHub Actions 平台更新怎样改变持续交付配置

GitHub Actions 最近的更新并没有要求你重写 runs-on 或重新学习一套 YAML 语法，但持续交付配置确实要补两层治理：一是多云 hosted runner 带来的出站 IP 变化，二是工作流依赖锁文件进入正式可用。前者影响网络连通和认证，后者影响 action 代码是否仍是经过审查的版本。

官方地址：https://github.blog/changelog/2026-10-28-github-actions-adds-multi-cloud-compute-to-improve-reliability/

这次平台变化到底改了哪一层

GitHub 的说明指出，Actions 会把符合条件的任务调度到可用的多个云计算提供商，现有 runner 标签和 workflow 语法保持不变。因此，runs-on: ubuntu-latest 不需要因为这次更新就改成某个新标签。真正需要复盘的是“runner 能否访问内部服务”和“workflow 调用的 action 是否可追溯”。

多云 runner 变化先改网络边界

如果企业服务只允许某家云厂商的网段，任务换到扩大的计算池后，可能表现为下载依赖超时、访问制品库被拒绝，或 OIDC/内部 API 认证失败。不要把这些现象归因于 YAML 语法，先检查白名单是否来自 GitHub 公布的 Actions 地址集合。

部署一个定期同步任务时，建议把“拉取地址、生成差异、人工审批、更新策略”分开。下面的命令只是配置示例，注释说明了关键边界：

# 读取 GitHub Meta API，筛出 Actions runner 使用的地址集合
curl -fsSL https://api.github.com/meta | jq '.actions'

# 只在评审差异后更新企业防火墙或代理白名单
# 不要把一次手工复制的网段当成永久配置
./scripts/sync-actions-allowlist.sh --source meta-api --review

GitHub 文档建议以 Meta API 为同步来源，而不是按 Azure 等云厂商自行推断。对生产发布来说，网络策略更新应有回滚版本；如果新地址尚未被内部服务信任，先让构建任务进入灰度仓库，避免直接影响主分支发布。

锁文件把 action 依赖接入发布门禁

工作流通常写成 uses: owner/action@v3，标签可能移动，运行时解析到的 commit 也就可能变化。工作流依赖锁文件会在 .github/workflows/actions.lock 记录 action 及传递依赖的 commit，让被审查的代码与实际运行代码保持一致；它不会锁定 runner 镜像、输入参数或 secrets，也不会自动证明依赖安全。

# 安装官方 GitHub CLI 扩展，用于生成机器维护的锁文件
gh extension install github/gh-actions-lock

# 先检查 workflow 中的 uses，再生成锁文件；不要手工编辑 actions.lock
gh actions-lock .github/workflows/ci.yml

# 在合并前验证锁文件是否过期，失败时阻止发布门禁继续
gh actions-lock --verify

建议把生成的锁文件当作依赖变更来评审：commit 改变意味着 CI 实际执行的代码改变；如果 owner_id 或 repo_id 异常变化，应先调查仓库归属。Dependabot 可以在已接入锁文件的 workflow 中同步更新锁文件，但仍需要团队审查差异。

按风险分层改造持续交付

小团队可以先为部署 workflow 生成锁文件，并把 actions.lock 加入 CODEOWNERS；大型组织则先用评估模式观察覆盖范围，再启用 Require lockfile。两种方式都要保留可回退路径：网络白名单保存上一版，锁文件更新通过独立 PR 合并，发布任务只在验证成功后继续。

• 网络层：检查代理、数据库、制品库和条件访问是否依赖固定出口。
• 依赖层：逐个 onboarding workflow，确认 reusable workflow 在它自己的仓库也有治理。
• 权限层：按 job 设置最小 GITHUB_TOKEN 权限，部署环境配合并发组避免重复发布。
• 运营层：记录白名单更新时间、锁文件 commit 变化和失败通知，便于回滚与审计。

常见问题

要不要把 ubuntu-latest 改成固定版本？

不需要因为多云计算更新而强制改。是否固定 runner 镜像应由兼容性和可复现性决定，与这次多云调度是两个决策。

actions.lock 能替代完整 SHA 写法吗？

它能让可读的 tag 引用对应到锁定 commit，但 reusable workflow 的依赖治理仍要在被调用仓库处理；锁文件也不替代安全评审。

为什么配置没改却突然连不上内部服务？

优先检查 runner 出站地址是否进入企业白名单，再看代理、DNS、OIDC 和目标服务日志，最后才排查 workflow 步骤本身。

这两项更新的共同点是把持续交付从“能跑”推进到“可控”：网络配置要跟随平台地址来源维护，action 依赖要能复盘到具体 commit。先从部署链路中最关键的 workflow 试点，再扩大到全组织，迁移成本和故障半径都更可控。