持续集成：Github Actions

前言

持续集成指的是，频繁地（一天多次）将代码集成到主干。

它的好处主要有两个：
  1. 快速发现错误。每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易。
  2. 防止分支大幅偏离主干。如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。

持续集成的目的，就是让产品可以快速迭代，同时还能保持高质量。它的核心措施是，代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。

GitHub Actions 是 GitHub 的持续集成服务，于2018年10月推出，比 Travis CI 玩法更多。

GitHub Actions 是什么？

大家知道，持续集成由很多操作组成，比如抓取代码、运行测试、登录远程服务器，发布到第三方服务等等。GitHub 把这些操作就称为 actions。

很多操作在不同项目里面是类似的，完全可以共享。GitHub 注意到了这一点，想出了一个很妙的点子，允许开发者把每个操作写成独立的脚本文件，存放到代码仓库，使得其他开发者可以引用。

如果你需要某个 action，不必自己写复杂的脚本，直接引用他人写好的 action 即可，整个持续集成过程，就变成了一个 actions 的组合。这就是 GitHub Actions 最特别的地方。

简单来说，Actions就相当于持续集成中的某个特定功能的脚本，通过多个actions的自由组合，便可实现自己特定功能的持续集成服务

GitHub 做了一个官方市场，可以搜索到他人提交的 actions。另外，还有一个 awesome actions 的仓库，也可以找到不少 action。

GitHub Actions 有一些自己的术语。

（1）workflow （工作流程）：持续集成一次运行的过程，就是一个 workflow。

（2）job （任务）：一个 workflow 由一个或多个 jobs 构成，含义是一次持续集成的运行，可以完成多个任务。

（3）step（步骤）：每个 job 由多个 step 构成，一步步完成。

（4）action （动作）：每个 step 可以依次执行一个或多个命令（action）。

workflow文件

GitHub Actions 的配置文件叫做workflow文件，存放在代码仓库的.github/workflows目录, 如下图所示：

workflow文件采用YAML格式，文件名可以任意取，但是后缀名统一为.yml，比如上图的package.yml。

语法

workflow文件的配置字段非常多，详见官方文档 。下面是一些基本字段：

name

workflow的名称。如果省略该字段，默认为当前workflow的文件名。

name: GitHub Actions Demo

on

on: 触发workflow的条件，通常是某些事件，例如：release、push、pull_request等。详细内容可以参照官方文档 。

# push 事件触发 workflow
on: push

# 可以是事件的数组
on: [push, pull_request]

# 指定触发事件时，可以限定分支或标签
on:
  push:
      branches:
       - master

jobs

workflow 的主体就是 job 字段，表示要执行的一项或者多项任务。

（1）jobs.<job_id>.namejob_id是任务的id，name是任务的描述。立足：

jobs:
  my_first_job:
    name: My first job
  my_second_job:
    name: My second job

上面代码 jobs 包含两个任务，job_id 分别是 my_first_job、my_second_job。

job_id 里面的 name 就是任务的说明。

（2）jobs.<job_id>.needs：指定当前任务的依赖关系，运行顺序。

jobs:
  job1:
  job2:
    needs: job1
  job3:
    needs: [job1, job2]

job1 必须先于 job2 完成，job3 等待 job1 和 job2 的完成才能运行。所以这个执行顺序是 job1、job2、job3。

（3）jobs<job_id>.runs-on：指定运行所需要的虚拟机环境。必填项，比如：

ubuntu-latest，ubuntu-18.04或ubuntu-16.04

windows-latest，windows-2019或windows-2016

macOS-latest或macOS-10.14

看个例子：

jobs:
  build:
    # The CMake configure and build commands are platform agnostic and should work equally
    # well on Windows or Mac.  You can convert this to a matrix build if you need
    # cross-platform coverage.
    # See: https://docs.github.com/en/free-pro-team@latest/actions/learn-github-actions/managing-complex-workflows#using-a-build-matrix
    runs-on: ubuntu-latest

（4）jobs<job_id>.steps
steps指定每个任务的运行步骤，可以包含一个或多个步骤。

• jobs.< job_id>.steps.name：步骤名称。
• jobs.< job_id>.steps.run：该步骤运行的命令或者 action。
• jobs.< job_id>.steps.env：该步骤所需的环境变量。

name: Greeting from Mona
on: push

jobs:
  my-job:
    name: My Job
    runs-on: ubuntu-latest
    steps:
      - name: Print a greeting
        env:
          MY_VAR: Hi there! My name is
          FIRST_NAME: Mona
          MIDDLE_NAME: The
          LAST_NAME: Octocat
        run: |
          echo $MY_VAR $FIRST_NAME $MIDDLE_NAME $LAST_NAME.

看个例子：

name: learn-github-actions
on: [push]
jobs:
  check-bats-version:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-node@v2
        with:
          node-version: '14'
      - run: npm install -g bats
      - run: bats -v

• 创建了一个名称叫做 learn-github-actions 的 工作流。
• 有代码 push 到 Github 仓库时，触发该工作流。
• 定义了一个叫做 check-bats-version 的作业。
• 接下来是操作：这些操作可以是GitHub 社区创建的操作，也可以是自己的操作，如下：

• runner：运行器是安装了 GitHub Actions 运行器应用程序的服务器。 您可以使用 GitHub 托管的运行器或托管您自己的运行器。 运行器将侦听可用的作业，每次运行一个作业，并将进度、日志和结果报告回 GitHub。 GitHub 托管的运行器基于 Ubuntu Linux、Microsoft Windows 和 macOS，并且工作流程中的每个作业都在新的虚拟环境中运行。
  • 本例子的工作流，通过 yml 文件里的定义：runs-on: ubuntu-latest，工作于 Github 托管的 Ubuntu 服务器上。

代码第7行：- uses: actions/checkout@v2

uses 关键字指示作业检索名为 actions/checkout@v2 的社区操作的 v2。

这是检出仓库并将其下载到运行器的操作，允许针对您的代码运行操作（例如测试工具）。 只要工作流程针对仓库的代码运行，或者您使用仓库中定义的操作，您都必须使用检出操作。

- uses: actions/setup-node@v2
        with:
          node-version: '14'

安装 Node.js 运行环境到托管服务器上，版本为 14

这个工作流逻辑的可视化版本如下：