Skip to main content

GitHub Actions

GitHub Actions 是 GitHub 提供的 CI/CD 自动化工具,可以自动执行构建、测试、部署等工作流程。 对公开仓库是免费不限额度的,私有仓库每月有免费额度。

基本概念

  • Workflow(工作流):自动化流程,由一个或多个 job 组成
  • Job(任务):一组在同一 runner 上执行的 steps
  • Step(步骤):单个任务,可以是 action 或 shell 命令
  • Action(动作):可复用的最小单元
  • Runner(运行器):执行工作流的服务器

基本语法

工作流配置文件使用 YAML 格式,存放在 .github/workflows/ 目录。

最简单的工作流

完整示例

触发事件

Push 事件

Pull Request 事件

定时任务

手动触发

常用 Actions

Checkout 代码

设置 Node.js

设置 Python

缓存依赖

上传构建产物

下载构建产物

自动发布 Release

创建 Release

自动生成 Release Notes

Self-hosted Runner

自托管运行器允许在自己的服务器上运行工作流。

添加 Runner

  1. 进入仓库 Settings → Actions → Runners → New self-hosted runner
  2. 根据提示在服务器上安装和配置
  3. 启动 runner

安装(Linux)

使用 Self-hosted Runner

标签选择

Secrets 管理

添加 Secret

Settings → Secrets and variables → Actions → New repository secret

使用 Secret

矩阵构建

条件执行

实用示例

自动部署到服务器

Docker 构建和推送

代码检查

最佳实践

  1. 使用缓存:加速依赖安装
  2. 矩阵构建:多环境测试
  3. 并行执行:多个独立 job
  4. 合理使用 if:条件执行节省资源
  5. 保护 secrets:不要在日志中输出
  6. 使用官方 actions:更可靠和维护良好
  7. 限制权限:按需设置 permissions
  8. 准备 CI 降级方案 — GitHub Actions 经常宕机;考虑自托管 Runner 或备用 CI 平台

平台可靠性风险

GitHub Actions 在 2025–2026 年经历了多次频繁宕机。Mitchell Hashimoto(Vagrant 和 Terraform 创造者,2008年注册的 GitHub 第 1299 号用户)于 2026年4月宣布他的开源项目 Ghostty 离开 GitHub,主要原因就是 CI/CD 可持续性问题:
“我开始给每天打 X,标记 GitHub 宕机影响工作的日子。几乎每天都有 X。”
当你的 CI/CD 平台经常宕机数小时,它就成了生产力风险,不只是不便。对严肃项目,考虑:
  • 自托管 Runner 作为降级方案(见上方自托管 Runner 章节)
  • 备选 CI 平台(CircleCI、Buildkite、Gitea Actions)
  • 镜像仓库到其他平台,以便快速切换 CI
  • 不要把整个工作流绑在一个平台的可用性上

降级策略

  1. 自托管 Runner — 在自己的基础设施上跑工作流,不受 GitHub 宕机影响
  2. 多平台 CI — 把关键工作流镜像到备选平台(CircleCI、Buildkite)
  3. 先本地测试 — 推送前本地跑 lint/typecheck/test;CI 应是门槛,不是瓶颈
  4. 缓存用足 — 减少任务时长,宕机造成的阻塞时间更短
  5. 只读 GitHub 镜像 — 保留 GitHub 作为发现渠道,但 CI 放别处

参考资源

最后修改于 2026年8月31日