GitHub Actions

它是什么

GitHub Actions 是 GitHub 内置的 CI/CD 系统。你在仓库里添加一个 YAML 文件来描述工作流（workflow）——也就是在 push、pull request 或定时计划等事件发生时自动运行的一组步骤。每个工作流都在 GitHub 托管的机器（称为"runner"）上运行，因此你无需管理任何自有服务器就能测试、构建和部署代码。它是把"代码已推送"自动化到"应用已上线"最常见的方式。

优势

• 直接内置于 GitHub——无需另设独立的 CI 服务。
• 由仓库事件触发：在每个 PR 上跑测试，在每次推送到 main 时部署。
• 庞大的可复用 action 市场，覆盖常见任务（环境配置、部署、检查）。
• 为 Linux、macOS 和 Windows 提供托管 runner；对公开仓库有慷慨的免费分钟数。
• 提供密钥管理和环境保护，让部署更安全。

取舍

• YAML 工作流很快就会变复杂；调试失败的流水线可能很繁琐。
• 私有仓库的分钟数是计量收费的，重度使用会花钱。
• 由于它在远程 runner 上运行，在本地重现失败很别扭。
• 第三方 action 很方便，但它们是需要审核的供应链依赖。

最适合

直接从仓库自动化测试、构建和部署——在每个 pull request 上运行你的测试套件，并在 main 更新时部署到你的托管服务（比如 Cloudflare Pages）。

与 vibe coding 的契合度

GitHub Actions 与 vibe coding 是绝配，因为 AI 助手可以为你写出整条流水线。让它添加一个工作流，安装依赖、运行测试，并在推送到 main 时部署——它知道常见的 action 名称和 YAML 结构。真正的价值在于它是一张安全网：一旦每次变更都自动跑测试，AI 就无法悄悄合入会破坏构建的东西。提示：告诉 AI 助手你的托管服务和包管理器，好让它挑选正确的部署 action 和缓存设置，并把密钥放在仓库设置里，绝不要放进 YAML。

# .github/workflows/ci.yml
name: CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20 }
      - run: npm ci
      - run: npm test