5 分钟快速入门 Github Actions

GitHub Actions 是 GitHub 官方提供的 CI/CD 解决方案，它内置于 GitHub 平台，用于自动化你的软件构建、测试和部署工作流。

---

🚀 快速入门 GitHub Actions：自动化你的开发流程

核心概念：理解 Actions 的基石

在开始编写配置文件之前，理解以下几个关键概念是掌握 GitHub Actions 的前提：

1. Workflow（工作流程）

这是 GitHub CI/CD 的最高级别组件。Workflow 是一个 YAML 格式的文件，用于定义完整的自动化流程。

• 存储位置： 必须位于项目根目录下的 .github/workflows/ 文件夹内。
• 触发机制： 定义了什么事件（如 push、pull_request、定时任务等）会触发这个流程运行。

2. Job（作业）

Job 是 Workflow 中定义的一组任务，它们可以在不同的 Runner 上并行执行。

• 阶段划分： 类似于 GitLab CI 的 Stage，但 Job 默认并行。如果需要按顺序执行，可以使用 needs 关键字。
• 运行环境： 使用 runs-on 关键字指定运行环境，如 ubuntu-latest、windows-latest 或自托管 Runner。

3. Step（步骤）

Step 是 Job 中最小的执行单元，定义了要执行的具体操作。一个 Job 由多个 Step 组成，按顺序执行。Step 可以是：

• Action： 使用已有的、预打包的操作（如 actions/checkout@v4）。
• Shell 命令： 直接执行 Shell 脚本 (run: npm install)。

4. Action（操作）

Action 是 GitHub Actions 最大的特色。它是可复用、封装好的代码块，由社区或 GitHub 官方提供。

• 复用性： 让你无需从头编写脚本，即可完成检出代码、设置环境、上传产物等复杂任务。
• 格式： 使用 uses: owner/repo@ref 格式引用。

---

⚙️ 动手实践：编写你的第一个 Workflow

我们将创建一个简单的 Node.js 项目工作流，包含"安装依赖"和"运行测试"两个步骤。

1. 创建工作流文件

在你的 GitHub 仓库中，创建路径和文件：.github/workflows/ci.yml

2. 编写 ci.yml 内容

# .github/workflows/ci.yml

# 1. Workflow 名称
name: Node.js CI

# 2. 触发机制：何时运行？
on:
  push:
    branches: [ main, develop ] # 在 main 或 develop 分支有推送时触发
  pull_request:
    branches: [ main ]          # 在向 main 分支发起 Pull Request 时触发

# 3. 定义 Job (作业)
jobs:
  build_and_test: # Job 的 ID
    name: Build and Test
    
    # 4. 运行环境：在哪台机器上运行？
    runs-on: ubuntu-latest # 使用 GitHub 托管的最新版 Ubuntu Runner

    # 5. 定义 Step (步骤)
    steps:
    
      # Step 1: 检出代码 (使用官方 Action)
    - name: Checkout Repository
      uses: actions/checkout@v4 # 必须的步骤，将仓库代码下载到 Runner 上
      
      # Step 2: 设置 Node.js 环境 (使用官方 Action)
    - name: Set up Node.js
      uses: actions/setup-node@v4
      with:
        node-version: '20' # 指定使用的 Node.js 版本
        cache: 'npm'       # 启用 npm 缓存，加快后续运行速度
        
      # Step 3: 安装依赖 (使用 Shell 命令)
    - name: Install Dependencies
      run: npm ci # 使用 npm ci 确保干净安装，适用于 CI/CD
      
      # Step 4: 运行测试 (使用 Shell 命令)
    - name: Run Unit Tests
      run: npm test

3. 提交并查看结果

1. 将上述 ci.yml 文件提交并推送到你的 GitHub 仓库。
2. 进入你的 GitHub 仓库，点击顶部的 Actions 标签页。
3. 你会看到一个名为 Node.js CI 的新 Workflow 正在运行。
4. 点击进入，你可以看到 Build and Test Job 及其所有 Step 的实时日志输出。

---

🚀 进阶配置：让 Actions 更强大

1. 部署 Job (使用 needs 排序)

如果你想在测试成功后，再执行部署 Job，你需要使用 needs 来定义 Job 的依赖关系：

jobs:
  # 1. 测试 Job
  test:
    name: Run Tests
    runs-on: ubuntu-latest
    steps:
      # ... (检出代码, 设置环境, npm install, npm test 的步骤) ...
      
  # 2. 部署 Job：依赖测试 Job 成功
  deploy:
    name: Deploy to Production
    runs-on: ubuntu-latest
    needs: [test] # 明确指定：只有 test Job 成功后，才运行 deploy Job
    environment: production # 关联到 GitHub 环境，用于审批和保护
    steps:
      # Step 1: 配置云服务凭证
    - name: Configure AWS Credentials
      uses: aws-actions/configure-aws-credentials@v4
      with:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }} # 使用 Secrets 存储敏感信息
        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        aws-region: ap-southeast-1
        
      # Step 2: 执行部署命令
    - name: Deploy Application
      run: |
        npm run build
        aws s3 sync ./build s3://my-prod-bucket --delete

🔑 安全提示： 部署 Job 中使用的敏感信息（如 API 密钥、密码）绝对不应 直接写在 YAML 文件中，而应存储在 GitHub 仓库的 Settings > Secrets and variables > Actions 中。

2. 矩阵构建（Strategy Matrix）

如果你需要针对多个操作系统、Node 版本或浏览器版本运行相同的测试，使用矩阵策略可以大大简化配置：

jobs:
  test:
    runs-on: ${{ matrix.os }} # 运行时依赖 matrix.os 的值

    strategy:
      matrix:
        node-version: [18, 20, 22] # 三个 Node 版本
        os: [ubuntu-latest, windows-latest] # 两个操作系统

    steps:
      # ...
      - name: Set up Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
      # ...
      # 这个 Job 将运行 3 x 2 = 6 次，每个组合运行一次。

---

总结与下一步

恭喜你，现在你已经掌握了 GitHub Actions 的核心概念和基础工作流。

概念	作用	配置文件中的关键字	相当于 GitLab CI
Workflow	自动化流程的定义文件	name, on	Pipeline
Job	一组任务的集合，默认并行	jobs, runs-on, needs	Stage
Step	最小执行单元	name, uses, run	Job / Script
Action	可复用的代码块	uses:	(无直接对应，是 Actions 特色)

你的下一步：

1. 在你的 GitHub 仓库中，创建 .github/workflows/ci.yml 文件。
2. 尝试使用 on: schedule: 来定义一个定时运行的工作流，例如每天凌晨运行一次健康检查。