GitHub Actions 交互式学习

深入理解 CI/CD 自动化的核心引擎 — 从 Workflow 语法到管线执行，一步步掌握 GitHub Actions 的完整工作流程

🧩 核心概念

GitHub Actions 的架构由三层组成：Workflow → Job → Step。点击展开了解每一层。

Workflow（工作流） 核心

Workflow 是 GitHub Actions 的顶层概念，定义在仓库的 .github/workflows/ 目录下的 YAML 文件中。一个仓库可以有多个 Workflow。

关键属性

  • name：工作流名称，显示在 Actions 标签页中
  • on：触发条件（事件类型、分支过滤、定时 cron 等）
  • jobs：包含一个或多个 Job 的集合
  • env：所有 Job 共享的环境变量
  • permissions：GITHUB_TOKEN 的权限范围

一个仓库可以有多个 Workflow 文件

例如：ci.yml（持续集成）、deploy.yml（部署）、nightly.yml（定时任务）各自独立运行。

Job（作业） 核心

Job 是 Workflow 中的独立执行单元，每个 Job 在独立的 Runner（虚拟机）上运行。多个 Job 默认并行执行。

关键属性

  • runs-on：指定运行环境（ubuntu-latest、windows-latest、macos-latest）
  • needs：声明 Job 间的依赖关系，被依赖的 Job 成功后才执行
  • steps：Job 内的有序步骤列表
  • strategy.matrix：矩阵策略，在多个参数组合上并行运行
  • if：条件表达式，控制 Job 是否执行
  • timeout-minutes：超时时间（默认 360 分钟）
  • services：Job 可用的服务容器（如 Redis、PostgreSQL）
Step（步骤） 核心

Step 是 Job 内的最小执行单元。每个 Step 要么运行一段 Shell 命令（run），要么调用一个预构建的 Action（uses）。

两种 Step 类型

  • run：执行 Shell 命令，如 run: npm test、run: echo "Hello"
  • uses：引用一个 Action，如 uses: actions/checkout@v4

常用属性

  • name：步骤名称（显示在日志中）
  • with：传递给 Action 的参数
  • env：该步骤的环境变量
  • if：条件执行
  • continue-on-error：即使失败也继续执行后续步骤
Runner（运行器） 配置

Runner 是执行 Job 的服务器。GitHub 提供托管 Runner，也可以自建。

GitHub-hosted Runners

  • ubuntu-latest（Ubuntu 22.04/24.04，最常用，最快启动）
  • windows-latest（Windows Server 2022）
  • macos-latest（macOS 14/15）

Self-hosted Runners

部署在自己的服务器/容器中，适合需要特殊硬件、软件或网络环境的场景。通过 runs-on: self-hosted 指定。

Actions（动作/插件） 进阶

Action 是 GitHub 生态中可复用的自动化单元，发布在 GitHub Marketplace 上。通过 uses 引用。

引用方式

  • 官方 Action：actions/checkout@v4、actions/setup-node@v4
  • 社区 Action：docker/build-push-action@v5
  • 本地 Action：uses: ./.github/actions/my-action
  • 版本锁定：@v4（标签）或 @sha256:abc123（SHA，更安全）

三种 Action 类型

  • Docker Action：用 Dockerfile 定义，灵活但较慢
  • JavaScript Action：直接在 Runner 上运行 Node.js，快速
  • Composite Action：组合多个 Step 为一个 Action

▶️ 工作流执行模拟

选择一个触发事件，然后点击 "Run workflow" 观察工作流如何被触发和执行。点击每个 Step 可以展开查看日志。

📦 my-awesome-app main
选择事件并点击 "Run workflow" 开始模拟

📄 YAML 语法解析器

点击左侧 YAML 代码中的任意一行，右侧会显示详细解释。这是理解 Workflow 文件最直观的方式。

← 点击代码行查看说明
这个交互式解析器帮助你理解 GitHub Actions Workflow YAML 文件的每一行含义。点击左侧任意一行代码，这里就会显示对应的详细解释。
💡 Workflow YAML 文件必须放在仓库的 .github/workflows/ 目录下

⚡ 触发事件详解

GitHub Actions 支持 30+ 种事件触发器。点击卡片了解每种事件的用法和配置方式。

🔢 矩阵构建配置器

矩阵策略（Matrix Strategy）让你在一个 Job 定义中同时在多个参数组合上运行。选择参数，实时查看生成的构建组合和对应的 YAML。

Matrix Strategy 配置器
构建组合: 0

🔐 Secrets 与变量管理

Secrets 是加密的敏感数据，在日志中自动遮蔽。点击值区域模拟"查看"行为，了解安全最佳实践。

Repository Secrets 管理面板
🔑 DOCKER_PASSWORD ••••••••••
🔑 AWS_ACCESS_KEY_ID ••••••••••
🔑 NPM_TOKEN ••••••••••
🌐 DEPLOY_URL ••••••••••
⚠️ 在真实环境中，Secrets 永远不会以明文显示。这里只是模拟展示。在 Workflow 中通过 ${{ secrets.NAME }} 引用。GitHub 会自动在日志中遮蔽 Secret 值。

📚 关键术语

Workflow
定义在 .github/workflows/ 下的自动化流程，由一个或多个 Job 组成。
Job
Workflow 中的独立执行单元，在独立的 Runner 上运行。
Step
Job 内的最小执行单元，执行一条命令或调用一个 Action。
Runner
执行 Job 的服务器，GitHub 托管或自行部署。
Action
可复用的自动化插件，通过 uses 引用。
Event / Trigger
触发 Workflow 的事件，如 push、pull_request、schedule 等。
Artifact
Job 产出的文件，通过 upload/download-artifact 在不同 Job 间传递。
Secrets
加密存储的敏感数据（密码、Token），在日志中自动遮蔽。
Matrix Strategy
在一个 Job 定义中指定多个参数组合，实现并行构建。
needs
声明 Job 间的依赖关系，被依赖 Job 成功后才执行。
GITHUB_TOKEN
GitHub 自动为每个 Workflow Run 生成的临时 Token，用于 API 调用。
Composite Action
将多个 Step 组合为一个可复用 Action，通过 action.yml 定义。

🎯 自测测验

检验你对 GitHub Actions 核心概念的理解，10 道题目，即时反馈。

0%

总结

GitHub Actions 是深度集成在 GitHub 生态中的 CI/CD 平台。它的核心架构是 Workflow → Job → Step 三层结构，通过 YAML 文件声明式定义。丰富的触发事件（30+）覆盖了从代码提交到 Issue 创建的几乎所有 GitHub 场景。

掌握 GitHub Actions 的关键在于：理解 YAML 语法结构、善用 Marketplace 上的现成 Action、利用矩阵策略提升并行效率、通过 Secrets 安全管理敏感信息、以及用 needs 编排多 Job 的依赖关系。这个交互式页面涵盖了从基础到进阶的核心知识，随时可以回顾。