当前位置：首页 > 文章列表 > 科技周边 > 业界新闻 > GitHub Actions 九月更新有哪些工作流变化

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

来源：17golang原创 2026-09-05 23:06:39 0浏览收藏

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

要点速览

新增 runner 版本弃用查询 API，可看到注册支持和运行时支持的截止时间。
vulnerability-alerts 权限支持 read 与 none，可以把读取 Dependabot alerts 的权限单独收窄。
reusable workflow 新增四个 job.workflow_* 属性，但 GitHub Enterprise Server 暂不提供。

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

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

更新	实际解决的问题	需要记住的边界
runner deprecations REST API	提前安排 runner 升级，避免注册或运行时支持突然结束	返回的是某个版本的支持时间，不是替你完成升级
`vulnerability-alerts`	只给工作流读取 Dependabot alerts 的权限	只支持 `read` 和 `none`，仍要按工作流实际需求配置
`job.workflow_*`	在复用工作流中识别真正定义当前 job 的文件	GitHub Enterprise Server 不提供这些属性

GitHub Actions runner 生命周期、GITHUB_TOKEN 最小权限和 reusable workflow 来源定位三项更新的关系图 — 图1：三项更新分别落在 runner 生命周期、令牌权限和 reusable workflow 定位三个工程边界。

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 的实际来源。

GitHub Actions caller workflow 调用 reusable workflow 时 job.workflow_ref 等属性定位定义当前 job 的文件 — 图2：在 reusable workflow 中，`job.workflow_*` 指向定义当前 job 的文件，与调用方层面的 `github.workflow_*` 不是同一层信息。

如果 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 有了升级时间线，令牌有了更窄的权限边界，复用工作流也有了可追踪的来源信息。