Reusable Workflows

May 28, 2026 · View on GitHub

原文链接:

1. 解决什么问题

多仓库团队最容易出现 CI 分裂:

  • 每个仓库一份复制粘贴的 workflow
  • Node、Java、Go、Python 检查方式不一致
  • 安全扫描有的仓库有,有的仓库没有
  • job 名称不统一,分支保护很难配置
  • 模板改一次,要手工改几十个仓库

Reusable workflows 用 workflow_call 把公共 CI 逻辑抽出来,让业务仓库调用统一模板。

2. 基本结构

公共仓库:

org/.github
  .github/workflows/
    java-ci.yml
    node-ci.yml
    security-scan.yml

公共 workflow:

name: java-ci

on:
  workflow_call:
    inputs:
      java-version:
        required: false
        type: string
        default: "17"

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: ${{ inputs.java-version }}
      - run: mvn test

业务仓库调用:

name: ci

on:
  pull_request:
  push:
    branches: [main]

jobs:
  java-ci:
    uses: org/.github/.github/workflows/java-ci.yml@v1
    with:
      java-version: "21"

3. 多仓库治理建议

固定版本

业务仓库调用公共 workflow 时,不要长期使用 @main

推荐:

uses: org/.github/.github/workflows/java-ci.yml@v1

这样公共模板升级不会突然影响所有仓库。

job 名称稳定

分支保护依赖 status check 名称。

公共 workflow 的 job 名称要尽量稳定,避免改名导致主分支保护失效。

权限最小化

公共 workflow 里显式声明权限:

permissions:
  contents: read

需要写 PR 评论、上传安全结果、发布包时,再单独提高权限。

语言模板分层

不要写一个超级 workflow 处理所有语言。

建议按语言和职责拆:

  • java-ci.yml
  • node-ci.yml
  • go-ci.yml
  • docs-ci.yml
  • security-scan.yml
  • release.yml

4. 推广顺序

  1. 先选 1 个低风险仓库试点
  2. 抽出最小公共检查
  3. 稳定 job 名称和输出
  4. 给模板打 tag
  5. 推广到同类仓库
  6. 再把安全扫描、发布、镜像构建纳入模板

5. 常见风险

公共模板一次升级影响太多仓库

解决:用 tag 或 release 分层升级。

业务仓库完全失去灵活性

解决:公共模板提供少量输入参数,但不要把每个细节都参数化。

secrets 管理混乱

解决:能用 secrets: inherit 时也要明确边界,高风险 secret 要限制在必要仓库和环境。

6. 对本仓库的启发

40+ 微服务团队做 GitHub 工程治理时,Reusable workflows、Rulesets、CODEOWNERS 是三件基础设施。

它们分别解决:

  • CI 规则怎么统一
  • 分支和合入规则怎么统一
  • 代码责任怎么统一