github ci/cd_如何使用GitHub Actions建立轻量级，与工具无关的CI / CD流

github ci/cd

Agnostic tooling is the clever notion that you should be able to run your code in various environments. With many continuous integration and continuous development (CI/CD) apps available, agnostic tooling gives developers a big advantage: portability.

不可知论工具是一个聪明的想法，即您应该能够在各种环境中运行代码。 借助许多可用的持续集成和持续开发(CI / CD)应用程序，不可知论工具为开发人员提供了一个很大的优势：可移植性。

Of course, having your CI/CD work everywhere is a tall order. Popular CI apps for GitHub repositories alone use a multitude of configuration languages spanning Groovy, YAML, TOML, JSON, and more… all with differing syntax, of course. Porting workflows from one tool to another is more than a one-cup-of-coffee process.

当然，让CI / CD 随处可见都是一项艰巨的任务。 仅适用于GitHub存储库的流行CI应用程序就使用了多种配置语言，包括Groovy ， YAML ， TOML ， JSON等等。当然，这些语法都具有不同的语法。 将工作流程从一种工具移植到另一种工具不仅仅是一个杯咖啡的过程。

The introduction of GitHub Actions has the potential to add yet another tool to the mix; or, for the right set up, greatly simplify a CI/CD workflow.

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

Prior to this article, I accomplished my CD flow with several lashed-together apps. I used AWS Lambda to trigger site builds on a schedule. I had Netlify build on push triggers, as well as run image optimization, and then push my site to the public Pages repository. I used Travis CI in the public repository to test the HTML. All this  worked in conjunction with GitHub Pages, which actually hosts the site.

在撰写本文之前，我通过几个捆绑在一起的应用程序完成了CD流程。 我使用AWS Lambda来按计划触发网站构建。 我让Netlify建立在推送触发器上，并运行图像优化，然后将我的网站推送到公共Pages存储库。 我在公共存储库中使用Travis CI来测试HTML。 所有这些都与实际托管站点的GitHub Pages结合使用。

I’m now using the GitHub Actions beta to accomplish all the same tasks, with one portable Makefile of build instructions, and without any other CI/CD apps.

我现在正在使用GitHub Actions beta来完成所有相同的任务，并带有一个可移植的Makefile构建指令，并且没有任何其他CI / CD应用程序。

欣赏外壳 (Appreciating the shell)

What do most CI/CD tools have in common? They run your workflow  instructions in a shell environment! This is wonderful, because that means that most CI/CD tools can do anything that you can do in a  terminal… and you can do pretty much anything in a terminal.

大多数CI / CD工具有什么共同点？ 他们在外壳环境中运行您的工作流程说明！ 这太好了，因为这意味着大多数CI / CD工具都可以执行您可以在终端中执行的任何操作……而且您可以在终端中执行几乎所有操作 。

Especially for a contained use case like building my static site with a generator like Hugo, running it all in a shell is a no-brainer. To  tell the magic box what to do, we just need to write instructions.

特别是对于诸如用Hugo这样的生成器构建静态站点这样的封闭用例而言，在shell中运行所有这些都是理所当然的。 要告诉魔术盒该怎么办，我们只需要编写说明即可。

While a shell script is certainly the most portable option, I use the still-very-portable Make to write my process instructions. This provides me with some advantages over simple shell scripting, like the use of variables and macros, and the modularity of rules.

虽然shell脚本无疑是最可移植的选项，但我仍使用非常便携的Make来编写我的过程指令。 与简单的shell脚本相比，这为我提供了一些优势，例如变量和宏的使用以及规则的模块化。

I got into the nitty-gritty of my Makefile in my last post. Let’s look at how to get GitHub Actions to run it.

我在上一篇文章中了解了我的Makefile的本质 。 让我们看一下如何让GitHub Actions运行它。

在GitHub Actions中使用Makefile (Using a Makefile with GitHub Actions)

To our point on portability, my magic Makefile is stored right in the  repository root. Since it’s included with the code, I can run the Makefile locally on any system where I can clone the repository, provided I set the environment variables. Using GitHub Actions as my CI/CD tool is as straightforward as making Make go worky-worky.

就可移植性而言，我神奇的Makefile存储在存储库根目录中。 因为它包含在代码中，所以只要设置环境变量，我就可以在任何可以克隆存储库的系统上本地运行Makefile。 使用GitHub Actions作为我的CI / CD工具就像让Make go worky-worky一样简单。

I found the GitHub Actions workflow syntax guide to be pretty straightforward, though also lengthy on options. Here’s the necessary set up for getting the Makefile to run.

我发现GitHub Actions工作流程语法指南非常简单明了，尽管选项也很冗长。 这是运行Makefile的必要设置。

The workflow file at .github/workflows/make-master.yml contains the following:

.github/workflows/make-master.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

I’ll explain the components that make this work.

我将解释实现此目的的组件。

触发工作流程 (Triggering the workflow)

Actions support multiple triggers for a workflow. Using the on syntax, I’ve defined two triggers for mine: a push event to the master branch only, and a scheduled cron job.

动作支持工作流的多个触发器 。 使用on语法，我为我定义了两个触发器：仅对master分支的push事件和计划的 cron作业。

Once the make-master.yml file is in your repository, either of your triggers will cause Actions to run your Makefile. To see how  the last run went, you can also add a fun badge to the README.

将make-master.yml文件放入您的存储库后，任何一个触发器都将导致Actions运行您的Makefile。 要查看上次运行的情况，您还可以在自述文件中添加一个有趣的徽章 。

一件事 (One hacky thing)

Because the Makefile runs on every push to master, I sometimes would get errors when the site build had no changes. When Git, via my Makefile, attempted to commit to the Pages repository, no changes were detected and the commit would fail annoyingly:

因为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.

I came across some solutions that proposed using diff to check if a commit should be made, but this may not work for reasons. As a workaround, I simply added the current UTC time to my index page so that every build would contain a change to be committed.

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

环境和变量 (Environment and variables)

You can define the virtual environment for your workflow to run in using the runs-on syntax. The obvious best choice one I chose is Ubuntu. Using ubuntu-latest gets me the most updated version, whatever that happens to be when you're reading this.

您可以使用runs-on语法为工作流定义虚拟环境 ，以在其中runs-on 。 我选择的最明显的最佳选择是Ubuntu。 使用ubuntu-latest可以为我提供最新版本，无论您在阅读本文时发生了什么。

GitHub sets some default environment variables for workflows. The actions/checkout action with fetch-depth: 1 creates a copy of just the most recent commit your repository in the GITHUB_WORKSPACE variable. This allows the workflow to access the Makefile at GITHUB_WORKSPACE/Makefile. Without using the checkout action, the Makefile won't be found, and I get an error that looks like this:

GitHub为工作流设置一些默认环境变量 。 具有fetch-depth: 1 GITHUB_WORKSPACE fetch-depth: 1的actions/checkout动作 fetch-depth: 1在GITHUB_WORKSPACE变量中创建存储库中最新提交的GITHUB_WORKSPACE 。 这使工作流程可以访问GITHUB_WORKSPACE/Makefile 。 如果不使用checkout操作，将找不到Makefile，并且出现如下错误：

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

While there is a default GITHUB_TOKEN secret,  this is not the one I used. The default is only locally scoped to the  current repository. To be able to push to my separate GitHub Pages  repository, I created a personal access token scoped to public_repo and pass it in as the secrets.TOKEN encrypted variable. For a step-by-step, see Creating and using encrypted secrets.

虽然有一个默认的GITHUB_TOKEN密码 ，但这不是我使用的密码 。 默认值仅在本地范围内适用于当前存储库。 为了能够推到我的GitHub单独的页面库中，我创建了一个个人的访问令牌作用域public_repo ，并传递它作为secrets.TOKEN加密变量。 有关分步操作的信息，请参阅创建和使用加密的机密 。

便携式工具 (Portable tooling)

The nice thing about using a simple Makefile to define the bulk of my  CI/CD process is that it’s completely portable. I can run a Makefile  anywhere I have access to an environment, which is most CI/CD apps,  virtual instances, and, of course, on my local machine.

使用简单的Makefile定义CI / CD流程的大部分好处是它是完全可移植的。 我可以在任何可以访问环境的地方运行Makefile，该环境包括大多数CI / CD应用程序，虚拟实例，当然也可以在本地计算机上。

One of the reasons I like GitHub Actions is that getting my Makefile  to run was pretty straightforward. I think the syntax is well done - easy to read, and intuitive when it comes to finding an option you’re  looking for. For someone already using GitHub Pages, Actions provides a  pretty seamless CD experience; and if that should ever change, I can run my Makefile elsewhere. ¯\_(ツ)_/¯

我喜欢GitHub Actions的原因之一就是让我的Makefile运行起来非常简单。 我认为该语法做得很好-易于阅读，并且在查找所需选项时非常直观。 对于已经在使用GitHub Pages的用户，Actions提供了非常无缝的CD体验； 如果应该更改，我可以在其他地方运行我的Makefile。 ¯\ _(ツ)_ /¯

翻译自: https://www.freecodecamp.org/news/a-lightweight-tool-agnostic-ci-cd-flow-with-github-actions/

github ci/cd