使用 GitHub Actions 实现轻量级、与工具无关的 CI/CD 流程

不可知工具的概念很巧妙，它意味着你应该能够在各种环境中运行你的代码。随着众多持续集成和持续开发 (CI/CD) 应用的出现，不可知工具为开发人员带来了一大优势：可移植性。

当然，让你的 CI/CD在所有地方都能正常工作并非易事。仅GitHub 仓库的热门 CI 应用就使用了多种配置语言，包括Groovy、YAML、TOML、JSON等等……当然，所有这些语言的语法都各不相同。将工作流程从一个工具移植到另一个工具可不是喝杯咖啡就能搞定的。

GitHub Actions的引入有可能为组合添加另一个工具；或者，对于正确的设置，可以大大简化 CI/CD 工作流程。

在撰写本文之前，我使用几个捆绑在一起的应用程序完成了我的持续交付流程。我使用 AWS Lambda 按计划触发网站构建。我使用 Netlify 基于推送触发器进行构建，并运行图像优化，然后将我的网站推送到公共 Pages 仓库。我在公共仓库中使用 Travis CI 测试 HTML。所有这些都与实际托管网站的 GitHub Pages 协同工作。

我现在使用 GitHub Actions beta 来完成所有相同的任务，使用一个可移植的 Makefile构建说明，而无需任何其他 CI/CD 应用程序。

欣赏贝壳

大多数 CI/CD 工具有什么共同点？它们在 Shell 环境中运行你的工作流程指令！这很棒，因为这意味着大多数 CI/CD 工具都能完成你在终端中能做的所有事情……而你几乎可以在终端中完成所有事情。

尤其是对于像使用 Hugo 这样的生成器构建静态网站这种封闭的用例，在 shell 中运行所有操作简直是轻而易举。我们只需要编写指令，就能告诉这个“魔盒”该做什么。

虽然 Shell 脚本无疑是最易移植的选择，但我还是使用同样易移植的Make来编写流程指令。相比简单的 Shell 脚本，Make 为我提供了一些优势，例如变量和宏的使用，以及规则的模块化。

我在上一篇文章中详细介绍了Makefile。让我们看看如何让 GitHub Actions 运行它。

将 Makefile 与 GitHub Actions 结合使用

关于可移植性，我的 Makefile 就存储在仓库根目录下。由于它包含在代码中，只要设置好环境变量，我就可以在任何可以克隆仓库的系统上本地运行 Makefile。使用 GitHub Actions 作为我的 CI/CD 工具就像让 Make 运行起来一样简单。

我发现GitHub Actions 工作流语法指南相当简单易懂，尽管选项有点冗长。以下是运行 Makefile 所需的设置。

工作流文件.github/workflow.yml包含以下内容：

name: make-master

on:
  push:
    branches:
      - master
  schedule:
    - cron: '20 13 * * *'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@master
        with:
          fetch-depth: 1
      - name: Run Makefile
        env:
          TOKEN: ${{ secrets.TOKEN }}
        run: make all

我将解释实现这一功能的组件。

触发工作流程

操作支持工作流的多个触发器。使用on语法，我为我的工作流定义了两个触发器：一个仅推送到分支的事件master，以及一个计划 cron作业。

一旦workflow.yml文件添加到您的代码库中，您的任一触发器都会触发操作运行您的 Makefile。要查看上次运行的进度，您还可以在 README 文件中添加一个有趣的徽章。

一件骇人的事情

由于每次推送到 时都会运行 Makefile master，所以有时即使网站构建没有任何更改，也会出错。当 Git 通过我的 Makefile尝试提交到 Pages 仓库时，却没有检测到任何更改，提交会令人恼火地失败：

nothing to commit, working tree clean
On branch master
Your branch is up to date with 'origin/master'.
nothing to commit, working tree clean
Makefile:62: recipe for target 'deploy' failed
make: *** [deploy] Error 1
##[error]Process completed with exit code 2.

我遇到过一些解决方案，建议使用diff来检查是否应该提交，但由于某些原因，这可能行不通。作为一种解决方法，我简单地将当前 UTC 时间添加到我的索引页，以便每次构建都包含要提交的更改。

环境和变量

您可以使用语法定义工作流运行的虚拟环境runs-on。 显然的最佳选择我选择的是 Ubuntu。使用它ubuntu-latest可以获得最新版本，无论你读到这篇文章时是什么版本。

GitHub 为工作流设置了一些默认环境变量。withactions/checkout操作会fetch-depth: 1在变量中创建仓库中最新提交的副本GITHUB_WORKSPACE。这允许工作流访问 处的 Makefile GITHUB_WORKSPACE/Makefile。如果不使用 checkout 操作，则找不到 Makefile，我会收到如下错误：

make: *** No rule to make target 'all'.  Stop.
Running Makefile
##[error]Process completed with exit code 2.

虽然有一个默认的GITHUB_TOKENsecret，但我用的不是这个。默认 secret 的作用域仅限于当前仓库。为了能够推送到我单独的 GitHub Pages 仓库，我创建了一个个人访问令牌，作用域为 ，public_repo并将其作为加密变量传入secrets.TOKEN。有关分步说明，请参阅创建和使用加密 secret。

便携式工具

使用简单的 Makefile 来定义大部分 CI/CD 流程的好处在于它完全可移植。我可以在任何可以访问环境的地方运行 Makefile，例如大多数 CI/CD 应用、虚拟实例，当然还有我的本地机器。

我喜欢 GitHub Actions 的原因之一是，运行 Makefile 非常简单。我认为它的语法很棒——易于阅读，并且在查找所需选项时非常直观。对于已经在使用 GitHub Pages 的用户来说，Actions 提供了非常无缝的 CD 体验；如果情况发生变化，我可以在其他地方运行我的 Makefile。¯\_(ツ)_/¯