GitHub Actions：从自动测试到安全发布的工作流

最合适的第一个工作流是测试

先不要直接把自动化绑到生产部署。更稳妥的起点是：开发者提交 pull request 后，在隔离的执行环境安装依赖、执行格式检查和单元测试，只有全部通过才允许合并。这样能减少“在我电脑上没问题”的回归。

理解 workflow、job 与 step

一个工作流一般在仓库的 .github/workflows/ 目录中定义，包含触发条件、作业和步骤。作业可以在指定运行器上执行，步骤通常包括检出代码、安装运行时和执行命令。每次执行应能从日志定位失败步骤。

自动部署的安全底线

1. 不要把生产 token 写进 YAML 或提交记录。
2. 遵循最小权限配置，区分拉取请求的测试权限与发布权限。
3. 只在明确允许的分支或人工审批后发布生产环境。
4. 定期检查第三方 Actions 的来源与引用版本。

它和 Docker 的关系

Actions 是自动化执行平台；Docker 可用于构建与打包应用。一个常见组合是先运行测试，再构建镜像并推送到部署服务，但是否需要容器取决于项目类型。

先做一个只运行测试的最小工作流

在仓库创建 .github/workflows/ci.yml，先让 Pull Request 触发代码检查，不急着接入生产发布。下面是 Node.js 项目的示例，前提是仓库有锁文件并提供 npm test 脚本；其他项目应替换成对应语言的安装与测试命令。

name: CI
on: [pull_request]
permissions:
  contents: read
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm test

提交一个 Pull Request 后到 Actions 标签查看执行结果，故意提交一个失败的测试，确认仓库不会把“任务启动成功”误认为“测试通过”。示例中的 action 版本应在实际部署时核对并根据项目安全策略固定到可信版本或提交 SHA。

发布凭据不要直接暴露给每个 Pull Request

不要在来自外部贡献者的普通 Pull Request 流程中使用生产环境密钥；为发布作业单独设置触发条件、最小权限和审核。GITHUB_TOKEN 的权限可以通过 permissions 显式收紧。只有在测试、审查和环境保护规则都满足后，再考虑添加自动部署步骤。