很多人用 GitHub 只用来存代码，其实它自带一个强大的自动化引擎：GitHub Actions。简单说，它能让你的仓库"自己干活"——代码一提交就自动跑测试，每天定时执行任务，打个 tag 就自动发版。

Actions 是什么

想象你雇了个不知疲倦的助理，守在仓库门口：有人 push 代码，它就跑一遍测试；到了固定时间，它就执行你安排的任务；你打个版本号，它就打包发布。Actions 就是这个助理。公开仓库随便用，私人仓库每月也有免费额度，个人小项目根本用不完。

它由三个核心概念组成：

  • Workflow（工作流）：一份 YAML 配置文件，放在 .github/workflows/ 目录下，描述"什么时候、做什么"。一个仓库可以有多个 workflow。
  • Job（任务）：workflow 里的一组步骤，跑在一台 GitHub 提供的虚拟机上（Ubuntu、Windows、macOS 可选）。
  • Step（步骤）：具体的一条命令，比如"拉取代码"“安装依赖"“运行测试”。步骤可以顺序执行，也可以引用别人写好的现成动作。

触发方式（on）很灵活：代码 push、提 PR、定时（cron）、手动点击按钮、打 tag，都可以触发。

它能做什么：三大典型用法

1. 自动测试（CI）。每次 push 或提 PR，自动跑测试套件，测试挂了直接在 PR 页面标红，合并不了。这是"人肉测试"和"工程化"的分水岭。哪怕你的测试只有三行断言，跑起来就有意义。

2. 定时任务。用 cron 表达式定时触发，比如每天凌晨同步数据、每周生成一份报告、定期检查依赖有没有新版本。不用自己搭服务器挂脚本。

3. 自动发布。打个 tag，自动编译打包、生成 Release、上传构建产物。很多开源项目的"一键发版"就是这么实现的。

除此之外还有自动打标签、自动回复 issue、自动部署博客等玩法，GitHub 官方的 Marketplace 里有上万个现成动作，直接引用就行。

一个最简单的 workflow

下面是一个真实可用的最小例子：每次 push 到 main 分支，就在 Ubuntu 上跑一句 echo。

name: hello-actions
on:
  push:
    branches: [main]
jobs:
  hello:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: echo "仓库有新提交，Actions 已触发"

把这份文件存为 .github/workflows/hello.yml 推上去，去仓库的 Actions 标签页，就能看到它跑起来的记录，点进去还能看每一步的日志。从这个骨架出发，把 run 换成你的测试命令，就是一条真正的 CI 流水线。

再进一步，加个定时触发器，每天早上 8 点跑：

on:
  schedule:
    - cron: '0 0 * * *'  # 注意：这里是 UTC 时间，0 点即北京时间 8 点

进阶要过的两道坎

Secrets：密码、API Token 不能写进配置文件。用仓库 Settings 里的 Secrets 存，workflow 里用 ${{ secrets.MY_TOKEN }} 引用，日志里会自动打码。

看日志排错：Actions 跑失败了别慌，点进那次运行，每一步的日志都清清楚楚。90% 的失败都是 YAML 缩进、路径写错这类小问题。

新手建议

先从"定时跑个脚本"开始，这是最快建立体感的用法。比如每天定时检查你 Star 的仓库有没有新 Release——写个几十行脚本，加个 cron 触发器，一天就能跑通。

等熟悉了，直接去读优秀开源仓库的 .github/workflows 目录。看别人怎么写，是学 Actions 最快的方式——那些跑了几年的 workflow 文件本身就是最好的教材。

之前写过《GitHub 新手入门》，如果你连 Star 和 Fork 还没玩熟，建议先看那篇，再回来看这篇。