GitHub Actions CI 的无意全面介绍

GitHub Actions CI 模板

我们目前正在准备将 GitHub Actions v2 公开发布，供所有人使用。我个人对此非常兴奋，因为这意味着我不需要配置外部服务来运行我的 CI——我可以直接添加一些 YAML 文件，然后就可以拥有一个安装了多个 Node.js 版本的跨平台（！）CI 系统了。

对我来说，这简直是天赐之物。无需访问外部网站；一切都井井有条。不过，过去我使用其他 CI 服务（主要是 Travis CI 和 Azure Pipelines）时，通常只是从头复制粘贴别人的 CI 配置，然后再根据其他上下文进行调整。

不过，这次的先验知识很少。在 Actions v2 的 Beta 版本中，GitHub 发布了几个不同的 CI 模板，我可以从中复制/粘贴某些部分。但是，我要求我的所有项目都遵循以下几个标准：

• npm install应该传递所有操作系统的最新版本
• npm test应该传递所有操作系统的最新版本
• npm install并且应该在所有当前支持的Node.js 版本npm test上成功运行。

这意味着我每个项目随时都会运行着一个从 9（3 个版本乘以 3 个操作系统）到 12（4 个版本乘以 3 个操作系统）的 CI 矩阵。我发现，实现这一目标的具体方法因 CI 系统而异。

考虑到发布时不会有大量的现有技术，我想我会开始构建一些综合模板，以便在发布时人们可以轻松复制/粘贴一些内容，然后进行调整以满足他们的确切需求。

GitHub Actions CI 模板

在将 GitHub Actions CI 添加到good-first-issue之后，我认为我应该将 CI 文件抽象为一个 repo，这样更容易访问。

因此，昨晚我构建了GitHub Actions CI 模板。最初，我仅提供了一个模板，可以满足我对 Node.js 和 npm 的需求。但大约一个小时前，我又添加了两个模板：Node.js 和 Yarn，以及 Node.js 和 pnpm。

如果您想查看模板，就 YAML 而言，它们都相对简单：

• Node.js 跨平台：
  • 运行基于：
  • Ubuntu（最新版），
  • Windows（最新版），
  • macOS（最新版）
  • 使用 Node.js项目当前支持的所有版本的 Node.js ，
  • 使用npm install和npm test。
• Node.js 跨平台（使用 Yarn）
  • 运行基于：
  • Ubuntu（最新版），
  • Windows（最新版），
  • macOS（最新版）
  • 使用 Node.js项目当前支持的所有版本的 Node.js ，
  • 使用yarn install和yarn test。
• Node.js 跨平台（使用 pnpm）：
  • 运行基于：
  • Ubuntu（最新版），
  • Windows（最新版），
  • macOS（最新版）
  • 使用Node.js 项目当前支持的所有版本的 Node.js。
  • 使用pnpm install和pnpm test。

剖析模板的 GitHub Actions YAML

这些模板都遵循相对相似的结构。我想带你逐行浏览一下Node.js 跨平台文件的代码，以确保你能理解它们。让我们逐行来看，代码在顶部，描述在底部：

name: Node.js Cross-platform CI (using Yarn)

上面这一行是整个 CI 脚本的标题，它将显示在ActionsGitHub repo 的选项卡中。

相关文档：

• 工作流语法文档 -name

on: [push]

上面这行代码表示触发运行。对于大多数 CI 情况来说，[push]这很理想，因为您希望每次将代码推送到仓库或 PR 时都运行它。

相关文档：

• 工作流语法文档 -on
• 工作流触发器文档

jobs:

工作流由一个或多个作业组成。此行表示我们有多个作业需要运行。

相关文档：

• 工作流语法文档 -jobs
• 使用限制，有关工作限制的上下文

  build:

这是job_id我们具体工作的。由于我们正在运行构建，所以我给它起了个名字，build但这个特定名称在 GitHub Actions CI 内部没有任何语义含义。

相关文档：

• 工作流语法文档 -jobs.<job_id>

    runs-on: ${{ matrix.os }}

这是一个必需属性，它告诉 CI 运行应该在哪种类型的机器上运行。在我们的例子中，我们通过添加一个需要构建的操作系统矩阵来增加一些复杂性。也就是说，矩阵的上下文会被提升，我们可以在这里使用该上下文。

文档中需要注意的一个关键点：

每个作业都使用由 runs-on 指定的虚拟环境的新实例运行。

这意味着，每个作业都会运行所选操作系统的干净实例。这是持续集成的必要条件，但牢记这一点总是有用的。❤️

相关文档：

• 工作流语法文档 -jobs.<job_id>.runs-on
• GitHub Actions 的虚拟环境，列出了此属性的所有可能支持的值

    strategy:

使用一条strategy线是开始定义运行构建的环境矩阵的方式。

相关文档：

• 工作流语法文档 -jobs.<job_id>.strategy

      matrix:

矩阵的简单理解是，它是所有需要运行的上下文的集合。最简单的矩阵只有一行，例如，单个平台上的多个 Node.js 版本。

一个简单的矩阵：

话虽如此，JavaScript 和 Node.js 应用程序实际上可以在全球三大主流操作系统上运行，这是开发者工作流程的一部分。通常，我们希望在三大主流操作系统上运行，以确保不会出现特定于平台的意外错误——尤其是在开源领域，因为直接访问最终用户的途径很少。幸运的是，矩阵可以相对简单地解决这个问题。

通过添加多个操作系统，我们的矩阵变得更加复杂：

但是……这只是每个平台的最新版本。我们可能经常需要支持的旧版本怎么办？事实证明，我们也可以在 GitHub Actions CI 中使用每个平台的旧版本，这可能会使矩阵更加复杂：

目前 Node.js 的构建处于停工期。一年中有一半的时间（每年）会支持 4 个发行版本，大致如下：

矩阵非常有用，它能帮助我们以编程方式定义这样的列表，而无需逐个定义每个上下文。这种实用性主要体现在你开始添加更多平台和版本时，但值得庆幸的是，从配置方面来看，这样做的开销非常低（更多上下文信息请参阅以下部分）。

相关文档：

• 工作流语法文档 -jobs.<job_id>.strategy.matrix

        os: [ubuntu-latest, windows-latest, macOS-latest]

上面实际上是一个赋值给矩阵的变量，它可以被动态调用。在我们的例子中，我们只是说（所以）os上的变量将是这些变量中的每一个。至于具体实现方式，对我来说仍然有点不可思议，但是……它确实有效，似乎是通过在调用它们时迭代它们来实现的。当与另一个变量（例如）一起使用时，它们会被迭代，从而有效地创建类似上面表格的内容。matrixmatrix.osnode-version

相关文档：

• GitHub Actions 的虚拟环境，您可以在其中找到有关当前可用的所有操作系统的信息。

        node-version: [8.x, 10.x, 12.x]

我们将用另一个变量来定义我们想要运行的 Node.js 版本。

相关文档：

• actions/setup-node – 我们将版本传递给的 GitHub Action，它定义了版本可接受的语法
• GitHub Actions 虚拟环境中的软件——每个虚拟环境 (OS) 默认可用的软件详尽列表

    steps:

每个作业都包含一组steps。这一行表示我们将开始定义步骤。

相关文档：

• 工作流语法文档 -jobs.<job_id>.steps

    - uses: actions/checkout@v1

告诉我们的工作流程，我们将使用 GitHub Action，该 Action 可以actions/checkout在 [gihub.com/actions/checkout] 找到，它映射到 GitHub org/repo。另外值得注意的是，这是一个标记和发布的版本，可以在GitHub 的版本库@v1中找到。

相关文档：

• actions/checkout$GITHUB_WORKSPACE ，将您的存储库检出到虚拟环境中的操作。
• 工作流语法文档 -jobs.<job_id>.steps.uses

    - name: Use Node.js ${{ matrix.node-version }} on ${{ matrix.os }}

给定我们使用插入的各种变量，在作业所呈现的 UI 中显示该作业的名称matrix。

注意：似乎存在一个错误，导致无法正确呈现 - Actions UI 不是呈现为标记的模板文字，而是呈现为字符串。

相关文档：

• 工作流语法文档 -jobs.<job_id>.name

      uses: actions/setup-node@v1

定义一个外部操作——在本例中，是 1.xx 版本（通过 GitHub 仓库发布）的 [github.com/actions/setup-node] 操作。在我们的例子中，这个操作提供了一个非常便捷的接口，可以安装任意版本的 Node.js，而不是虚拟机自带的版本。我猜这会成为所有运行 JavaScript 或 Node.js 构建的用户的默认操作，因为它默认会帮你处理很多事情。

值得注意的是，所使用的操作uses:可以来自同一个存储库、公共存储库以及发布到 Docker Hub 的 Docker 镜像。

相关文档：

• 工作流语法文档 -jobs.<job_id>.steps.uses
• 操作/设置节点

      with:

这是操作中定义的参数map（我假设这是YAML 中 map 的定义）。在我们的例子中，需要一个版本来运行。mapactions/setup-node

相关文档：

• 工作流语法文档 -jobs.<job_id>.steps.with

        node-version: ${{ matrix.node-version }}

该actions/setup-node操作需要通过属性指定 Node.js 的版本才能运行node-version:。由于我们在 Matrix 中将变量命名为 Node.js 版本node-versions，因此我们可以将其传递matrix.node-version给该node-version:属性。

相关文档：

• 工作流语法文档 -jobs.<job_id>.steps.with
• 操作/设置节点

    - name: npm install and test

我们再次定义作业的名称。在这种情况下，没有动态信息，因为我们要运行的命令是相当静态的。

我使用npm install和npm test，但您的应用程序在安装/构建/测试/ci 命令方面可能会有所不同 - 我对此的建议是调整标题和实际命令，以便非常清楚正在运行的内容。

相关文档：

• 工作流语法文档 -jobs.<job_id>

      run: |
        npm install
        npm test

对于不熟悉 YAML 的人来说，这组代码很有趣。我们首先为run作业添加一个属性，它允许我们在系统上运行任何命令。在我们的例子中，我们将使用它来运行npm install……npm test但这是两个不同的命令，需要分别运行。管道 ( ) 是YAML 规范|中定义为文字样式的工具。在我们的例子中，它允许我们编写多行独立执行的代码，而无需使用多个命令或多个作业。基本上，它是一种简写方式，使我们能够更自由地构建文件。run:

注意：考虑到它是为 CI 环境量身定制的，使用它npm ci比npm install安装依赖项可能更值得。您可以在官方文档中找到更多详细信息。npm cinpm ci

相关文档：

• 工作流语法文档 -jobs.<job_id>.steps.run
• npm 安装
• npm 测试

      env:

允许我们相对轻松地在虚拟环境中设置环境变量。

相关文档：

• 工作流语法文档 -jobs.<job_id>.steps.env

        CI: true

这个是个人偏好，也恰好是 GitHub 建议的最简单的 Node.js 工作流程的默认设置。只需设置一个环境变量，即可轻松被各种工具使用。GitHub

相关文档：

• GitHub Actions 的虚拟环境 – 环境变量

下一步是什么？

目前，GitHub Actions CI 作为 GitHub Actions v2 的一部分处于半公开测试阶段——他们已经邀请了一些申请使用它的用户。话虽如此，如果你觉得这和去年 GitHub Actions 首次发布时的情况如出一辙，那么你会很高兴知道，在GitHub 特别活动中，Nat Friedman 分享了 GitHub Actions CI 和 GitHub Actions v2，并表示 GitHub Actions CI 和 GitHub Actions v2 以及 GitHub Package Registry 将于 11 月 13 日（ GitHub Universe的第一天）向所有人开放。

因此，从本文发布之日起仅一个多月后，您就可以开始在任何公共项目上免费使用 GitHub Actions CI。🎉

如果您对我在这篇文章中讨论的内容有任何问题或意见，或者您想了解有关 GitHub Actions CI 或 GitHub Actions v2 的更多信息，我很乐意看看我是否可以直接在评论中回答您的问题，制作优秀的免费和公共存储库来帮助您找到答案，或者如果您觉得有帮助的话，就这个主题写更多帖子！