讲解GitHub Actions 自动 CI 测试 WorkFlows工作流
介绍workflows
代码托管平台 Github 我们应该比较熟悉。每次我们提交代码到 GitHub 仓库时，特别是开源项目，一般都会自动触发测试脚本运行，帮你验证代码没有引入新的错误。
这个其实就是GitHub Actions，一般我们把 YAML 脚本定义在.github/workflows目录下。
一. 什么是 GitHub Actions 自动 CI 测试？
GitHub Actions是 GitHub 官方提供的一套自动化工作流服务，可以用来自动化代码构建、测试、部署等流程。CI（持续集成，Continuous Integration）测试是指在代码每次提交或者合并请求时，自动运行项目的测试代码，保证代码的正确性和稳定性。
那为什么要用 GitHub Actions 自动 CI 测试？原因也很简单：
自动化：减少人工手动测试的工作，省时省力。
快速反馈：提交代码后马上知道测试结果，发现问题及时修复。
保障质量：避免有问题的代码被合并进主分支，提升代码质量。
多平台支持：可以在不同操作系统和环境下自动测试，比如 Windows、Linux、macOS。
免费且无缝集成：直接集成在 GitHub 仓库，无需额外配置第三方服务。
常见的 CI 测试比如：Node.js 项目跑npm test、Python 项目跑pytest、Java 项目跑mvn test,还有Docker 镜像构建和测试等等。
讲解workflows
.github/workflows是 GitHub 强制约定的固定文件夹，专门存放GitHub Actions 的自动化配置文件；每一个.yml文件 = 一个独立Workflow（工作流），用来定义：在什么时机、在哪台机器、自动跑哪些任务。
下面从底层架构 → 目录规则 → 核心概念层级 → 所有语法关键字拆解 → 触发事件 → 运行机器 → 并行 / 串行 → 完整实例逐行注释 → 秘钥 / 环境变量 → 调试全套讲透。
一、先搞懂整体架构层级（最重要，理解这个就通了）
GitHub Actions 整套体系层级从大到小：
- Workflow 工作流对应一个
xxx.yml配置文件，一整套完整自动化流程 - Job 任务一个 Workflow 可以有多个 Job，每个 Job 独立一台虚拟机
- Step 步骤一个 Job 由多个 Step 组成，从上到下顺序执行
- Action 动作Step 里可直接调用别人写好的可复用模板（不用自己敲命令）
层级关系简图：
1个 yml工作流文件 ├─ Job1（独立虚拟机） │ ├─ Step1 拉代码 │ ├─ Step2 装依赖 │ └─ Step3 跑测试 └─ Job2（另一台独立虚拟机，默认和Job1同时跑） ├─ Step1 打包 └─ Step2 部署二、目录强制规则（为什么必须放这里）
必须严格固定路径，不能改名字、不能换位置：
仓库根目录 └── .github └── workflows 【固定死，必须叫这个】 ├── ci.yml ├── deploy.yml └── cron.yml- GitHub 是硬编码识别这个文件夹，放别的目录不会生效
- 里面可以放无数个 yml 文件，每个文件完全独立、互不干扰
- 后缀只能是
.yml/.yaml
三、Runner 运行机器是什么？
Job 实际跑在的服务器，叫Runner（运行器），分两种：
1. GitHub 托管 Runner（普通人都用这个，免费）
每次触发工作流，GitHub临时给你开一台全新虚拟机，跑完立刻销毁，环境干净隔离。常用系统：
ubuntu-latest（最常用）windows-latestmacos-latest
2. 自建托管 Runner
把你自己的电脑 / 服务器接入 GitHub，任务跑在你自己机器上，适合内网项目、特殊环境。
四、Workflow 所有核心关键字 逐字详解
给你标准模板，逐个字段翻译 + 作用：
# 1. 整个工作流的名字，显示在 GitHub Actions 页面 name: 前端CI自动测试 # 2. on：【核心】什么时候触发这个工作流 on: push: branches: [main, master] pull_request: branches: [main] # 3. jobs：定义所有任务 jobs: # jobID：自定义任务标识（随便起名） test-job: # 任务显示名称 name: 代码测试任务 # 在哪种系统上跑 runs-on: ubuntu-latest # 依赖其他任务（做串行执行，后面讲） needs: [] # 4. steps：当前任务的每一个步骤，按顺序执行 steps: # 步骤1：调用官方Action拉取代码 - name: 拉取仓库代码 uses: actions/checkout@v4 # 步骤2：执行原生 shell 命令 - name: 安装依赖 run: npm install # 步骤3：带条件执行 - name: 仅主分支打包 if: github.ref == 'refs/heads/main' run: npm run build关键字逐个解释
| 关键字 | 作用 |
|---|---|
name | 工作流 / 任务 / 步骤 的展示名称 |
on | 触发条件：什么时候自动跑 |
jobs | 定义一组并行 / 串行任务 |
runs-on | 指定运行的系统虚拟机 |
needs | 任务依赖，控制执行先后顺序 |
steps | 单个任务里的步骤列表 |
uses | 调用现成的 Action 模板 |
run | 执行原生终端命令 |
with | 给 Action 传配置参数 |
if | 条件判断，满足才执行当前步骤 / 任务 |
五、on 触发事件 全场景详解
on是最常用、最容易写错的，给你直接可用的 6 种写法：
- 所有代码推送都触发
on: push- 提交 PR 合并请求才触发
on: pull_request- 同时监听 push 和 PR
on: [push, pull_request]- 只监听指定分支
on: push: branches: [main, master] pull_request: branches: [main]- 定时任务（Cron 表达式，UTC 时间）
on: schedule: - cron: '0 0 * * *' # 每天零点执行- 手动点击按钮触发页面上点一下就跑，适合手动部署
on: workflow_dispatch:六、Job 并行 vs 串行
1. 默认：并行执行
两个 Job 不写needs，同时开两台虚拟机一起跑
jobs: test: runs-on: ubuntu-latest steps: ... deploy: runs-on: ubuntu-latest steps: ...2. 配置依赖：串行执行
让deploy必须等test跑完再执行
jobs: test: runs-on: ubuntu-latest steps: ... deploy: needs: test # 依赖 test 任务 runs-on: ubuntu-latest steps: ...七、环境变量 & 私密密钥 Secrets
1. 普通环境变量
全局可用：
env: NODE_ENV: production jobs:2. 私密变量（重点）
仓库 → Settings → Secrets and variables → 加变量用来存服务器密码、Token、密钥，日志里不会明文泄露使用方式：
run: echo ${{ secrets.SERVER_TOKEN }}八、最常用内置 Action（必记）
不用自己写复杂命令，直接调用官方轮子：
actions/checkout@v4：必用，把仓库代码拉到虚拟机actions/setup-node@v4：自动安装指定 Node 版本actions/setup-python@v5：自动安装 Pythonactions/upload-artifact：把打包产物上传保存actions/download-artifact：下载之前保存的产物
九、在哪里看运行日志、调试
- 仓库顶部导航 →Actions
- 左边看到所有 Workflow 列表
- 点进去能看：哪个 Job 失败、哪一步报错、完整日志
- 改完 yml 推送到仓库，自动重新触发测试
十、workflows 能干什么（实际落地场景）
- CI 持续集成：提交代码自动编译、自动跑单元测试、代码格式检查
- CD 持续部署：合并到主分支后，自动打包、自动部署到服务器 / 云平台
- 定时任务：每天定时备份数据库、定时爬取数据、定时清理日志
- 仓库自动化：PR 自动检查、自动打标签、自动关闭无效 Issue
十一、一句话总结
.github/workflows是GitHub 固定专属目录，不能改名换位- 里面每个 yml = 一个独立自动化工作流
- 结构：
on触发 → jobs任务 → steps步骤 → run/action执行 - 本质就是：不用自己服务器，GitHub 帮你免费跑自动化脚本