GitHub Actions 九月更新有哪些工作流变化

GitHub Actions 2026 年 9 月初这次更新，重点不是增加一个新的触发器，而是让持续集成系统更容易回答三个问题：runner 什么时候必须升级、工作流读取 Dependabot 告警需要多大权限、一个 reusable workflow 里的 job 到底由哪个文件定义。三项能力已经分别落到 REST API、GITHUB_TOKEN 权限和 job 上下文中。

三项更新分别解决什么问题

这次公告适合按工程任务拆开看，而不是把它当成一次 YAML 语法大改：

runner 版本弃用怎么提前排进升级计划

自托管 runner 容易出现“机器还在线，但版本已经接近淘汰”的情况。新 REST API 可以在 repository、organization 或 enterprise 层级查询指定 runner 版本：

GET /actions/runners/deprecations/{version}

响应里重点看 runner_version、runtime_deprecates_at 和 registration_deprecates_at。前者描述查询的版本，后两者分别对应运行时支持结束和新 runner 注册支持结束。工程上可以把它接到每周的 runner inventory 检查里：先收集当前版本，再按时间字段排序，给临近截止日期的版本创建升级工单。

这里不要把“查询到日期”误解成“GitHub 会自动替换 runner”。升级动作仍然要由团队完成，包括确认自定义工具链、镜像和标签是否兼容。API 的价值是把维护窗口变成可查询数据。

vulnerability-alerts 权限怎样写得更小

如果一个工作流只需要读取 Dependabot alerts，不必继续依赖更宽泛的令牌权限。可以在工作流顶层或具体 job 里写：

permissions:
  contents: read
  vulnerability-alerts: read

jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - name: Check dependency alerts
        run: echo "read Dependabot alerts here"

read 表示只读访问，none 则明确关闭这项权限。建议把权限声明放在需要它的最小范围内，并检查组织级默认权限，避免某个 job 因复制旧模板而继承不必要的能力。这个变化改善的是令牌边界，不会自动替你修复依赖漏洞。

reusable workflow 怎样定位真正的定义文件

复用工作流时，调用方和被调用方都可能有自己的文件路径。原来的 github.workflow_ref 与 github.workflow_sha 更偏向当前调用上下文；新属性把“定义当前 job 的工作流”单独暴露出来：

- name: Record workflow source
  run: |
    echo "ref=${{ job.workflow_ref }}"
    echo "sha=${{ job.workflow_sha }}"
    echo "repo=${{ job.workflow_repository }}"
    echo "file=${{ job.workflow_file_path }}"

四个属性分别是完整 ref、工作流文件的 commit SHA、定义文件所在的 owner/repo 以及相对仓库根目录的文件路径。它们适合写入审计日志、构建摘要或故障诊断信息：当多个仓库复用同一套 workflow 时，排查者能知道当前 job 的实际来源。

如果 job 直接定义在普通 workflow 中，job.workflow_ref 会与 github.workflow_ref 对应；只有进入 reusable workflow 场景，两者的定位差异才真正明显。还要注意，这四个属性当前不适用于 GitHub Enterprise Server，迁移脚本不要默认它们一定存在。

升级后可以按这张清单检查

• 把自托管 runner 版本与 deprecations API 的两个日期放进定期检查，按 registration 和 runtime 分别安排窗口。
• 搜索工作流中的 permissions，将只读 Dependabot alerts 的 job 改为 vulnerability-alerts: read，并保留必要的其他权限。
• 在 reusable workflow 的诊断输出中记录四个 job.workflow_* 值；对缺少这些值的 GHES 环境保留兼容分支。

这样处理后，这次九月更新就不只是“看过公告”：runner 有了升级时间线，令牌有了更窄的权限边界，复用工作流也有了可追踪的来源信息。

常见问题

runner deprecations API 会直接升级 runner 吗？

不会。它只返回指定版本的注册和运行时支持截止时间，升级、镜像替换和兼容性验证仍由团队安排。

vulnerability-alerts: read 能修改 Dependabot 告警吗？

公告定义的是只读权限。它适合读取告警并生成检查结果，不应被当成修改或关闭告警的写权限。

为什么 reusable workflow 里还要记录 workflow SHA？

文件路径能说明来源位置，SHA 能帮助把一次运行对应到当时的具体版本。两者一起记录，排查复用工作流变更时更可靠。

事实依据：GitHub Actions Early September 2026 updates；相关接口和上下文细节可继续查看 GitHub REST API 文档 与 Contexts reference。