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
- 进入仓库 Settings → Actions → Runners → New self-hosted runner
- 根据提示在服务器上安装和配置
- 启动 runner
安装(Linux)
使用 Self-hosted Runner
标签选择
Secrets 管理
添加 Secret
Settings → Secrets and variables → Actions → New repository secret使用 Secret
矩阵构建
条件执行
实用示例
自动部署到服务器
Docker 构建和推送
代码检查
最佳实践
- 使用缓存:加速依赖安装
- 矩阵构建:多环境测试
- 并行执行:多个独立 job
- 合理使用 if:条件执行节省资源
- 保护 secrets:不要在日志中输出
- 使用官方 actions:更可靠和维护良好
- 限制权限:按需设置 permissions
- 准备 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
- 不要把整个工作流绑在一个平台的可用性上
降级策略
- 自托管 Runner — 在自己的基础设施上跑工作流,不受 GitHub 宕机影响
- 多平台 CI — 把关键工作流镜像到备选平台(CircleCI、Buildkite)
- 先本地测试 — 推送前本地跑 lint/typecheck/test;CI 应是门槛,不是瓶颈
- 缓存用足 — 减少任务时长,宕机造成的阻塞时间更短
- 只读 GitHub 镜像 — 保留 GitHub 作为发现渠道,但 CI 放别处
