如何使用 GitHub Actions 为 CI 创建工作流？

9 分钟

可在此处了解适用于 CI 的 GitHub Actions 和工作流。

学习如何：

从模板创建工作流
了解 GitHub Actions 日志
针对多个目标进行测试
单独的生成和测试作业
保存并访问生成项目
审阅时自动标记 PR

从模板创建工作流

若要创建工作流，首先要使用模板。模板具有为你要实现的特定自动化类型预先配置的常见作业和步骤。如果不熟悉工作流、作业和步骤，请查看使用 GitHub Actions 自动执行开发任务模块。

在存储库主页上，选择“操作”选项卡，然后选择“新工作流”。

在“选择工作流”页上，有许多不同模板可供选择。一个示例是 Node.js 模板，该模板对节点依赖项进行干净安装、生成源代码，并针对不同版本的 Node 运行测试。另一个示例是 Python 包模板，该模板可安装 Python 依赖项，并跨不同版本的 Python 运行测试（包括 lint）。

在搜索框中，输入“Node.js”。

在搜索结果中，在 Node.js 窗格中，选择“配置”。

Screenshot showing GitHub Actions tab with the Node.js pane highlighted and the Node.js template selected.

在新创建的文件 node.js.yml 中，你会看到这个默认的 Node.js 模板工作流。

name: Node.js CI

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  build:

    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [14.x, 16.x, 18.x]

    steps:
    - uses: actions/checkout@v3
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v3
      with:
        node-version: ${{ matrix.node-version }}
        cache: 'npm'
    - run: npm ci
    - run: npm run build --if-present
    - run: npm test

请注意 on: 属性。此工作流在推送到存储库以及对主分支发出拉取请求时触发。

此工作流中有一个 job。回顾一下它的功能。

runs-on: 属性指定，对于操作系统，工作流在 ubuntu-latest 上运行。 node-version: 属性指定存在三个版本，每个版本分别用于 Node 版本 14.x、16.x 和 18.x。稍后，在自定义工作流时，我们会深入讨论 matrix 部分。

作业中的 steps 使用 GitHub Actions actions/checkout@v3 操作将代码从存储库导入到 VM，使用 actions/setup-node@v3 操作设置正确版本的 Node.js。我们指定要用 ${{ matrix.node-version }} 属性测试 Node.js 的三个版本。此属性引用我们之前定义的矩阵。 cache 属性指定用于在默认目录中缓存的包管理器。

此步骤的最后一部分执行 Node.js 项目使用的命令。 npm ci 命令安装来自“package-lock.json”文件的依赖项，npm run build --if-present 运行生成脚本（如果存在），而 npm test 运行测试框架。请注意，此模板包含同一作业中的生成和测试步骤。

若要了解有关 npm 的详细信息，请参阅 npm 文档：

生成的操作日志

当工作流运行时，它会生成一个日志，其中包含所发生事件以及任何错误或测试失败的详细信息。

如果出现错误或测试失败，日志里将显示红色的 ✖ 而不是绿色的复选标记 ✔。可以检查错误或失败的详细信息，以调查出现的情况。

GitHub Actions log with details on a failed test.

在练习中，需通过检查日志中的详细信息来识别失败的测试。可以从“Actions”选项卡访问日志。

自定义工作流模板

在本模块的开头，我们介绍了一个需要为团队设置 CI 的方案。这个 Node.js 模板就是一个很好的起点，但需要对其进行自定义以更好地满足自己团队的要求。你想要面向 Node 的不同版本和不同的操作系统。你还希望生成和测试步骤是单独的作业。

我们看看如何自定义工作流。

strategy:
  matrix:
    os: [ubuntu-latest, windows-latest]
    node-version: [16.x, 18.x]

在此处，我们配置了一个生成矩阵，用于跨多个操作系统和语言版本进行测试。这个矩阵会产生四个生成，每个生成对应于与每个版本的 Node 配对的每个操作系统。

四个生成及其所有测试将产生相当多的日志信息。可能很难对所有信息进行排序。在以下示例中，我们将展示如何将测试步骤移动到专用的测试作业。此作业针对多个目标进行测试。如果将生成和测试步骤分开，则更容易理解日志。

test:
  runs-on: ${{ matrix.os }}
  strategy:
    matrix:
      os: [ubuntu-latest, windows-latest]
      node-version: [16.x, 18.x]
  steps:
  - uses: actions/checkout@v3
  - name: Use Node.js ${{ matrix.node-version }}
    uses: actions/setup-node@v3
    with:
      node-version: ${{ matrix.node-version }}
  - name: npm install, and test
    run: |
      npm install
      npm test
    env:
      CI: true

什么是项目？

当工作流生成日志项目以外的内容时，此产品称为“项目”。例如，Node.js 生成将产生可部署的 Docker 容器。通过使用操作 actions/upload-artifact，可将此项目（即容器）上传到存储，通过使用操作 actions/download-artifact，可从存储空间下载该项目。

存储项目会在作业之间保留项目。每个作业都使用新的虚拟机 (VM) 实例，因此不能通过将项目保存在 VM 上来重用它。如果需要在不同的作业中使用项目，可以在一个作业中将项目上传到存储空间，并在另一个作业中进行下载。

项目存储

项目存储在 GitHub 的存储空间中。公共存储库的空间是免费的，专用存储库的部分空间免费，具体取决于帐户。 GitHub 可将项目存储 90 天。

请注意，在下面的工作流片段中，actions/upload-artifact@main 操作中有一个 path: 属性。此属性的值是存储项目的路径。此处，我们指定“public/”以将所有内容上传到目录。如果只想上传单个文件，则使用类似 public/mytext.txt 的内容。

  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: npm install and build webpack
        run: |
          npm install
          npm run build
      - uses: actions/upload-artifact@main
        with:
          name: webpack artifacts
          path: public/

若要下载项目以进行测试，生成必须已成功完成项目并将其上传。在下面的代码中，我们指定测试作业依赖于生成作业。

test:
    needs: build
    runs-on: ubuntu-latest

在以下工作流代码片段中，我们下载该项目。现在，测试作业可以使用项目进行测试。

steps:
    - uses: actions/checkout@v3
    - uses: actions/download-artifact@main
      with:
        name: webpack artifacts
        path: public

若要详细了解如何在工作流中使用项目，请参阅 GitHub 文档中的将工作流数据存储为项目。

使用工作流在 GitHub 中自动进行审阅

到目前为止，我们讨论过使用 GitHub 事件（如 push 或 pull-request）启动工作流。我们还可以按计划或在 GitHub 之外的某个事件上运行工作流。

有时，我们希望仅在某人执行某个操作后运行工作流。例如，我们可能只想要在审阅者批准拉取请求后运行工作流。对于此方案，我们可以在 pull-request-review 上触发。

我们可以执行的另一个操作是将标签添加到拉取请求。在这种情况下，我们将使用 pullreminders/label-when-approved-action 操作。

    steps:
     - name: Label when approved
       uses: pullreminders/label-when-approved-action@main
       env:
         APPROVALS: "1"
         GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
         ADD_LABEL: "approved"

请注意称为 env: 的块。此块是为此操作设置环境变量的位置。例如，可以设置所需的审批者数量。这里有一个。 secrets.GITHUB_TOKEN 身份验证变量是必需的，因为该操作必须通过添加标签来更改存储库。最后，提供要添加的标签的名称。

添加标签可能是启动另一个工作流（例如合并）的事件。我们将在下一个模块中介绍这一点，该模块介绍 GitHub Actions 的持续交付。