在上一节我们学习了如何构建本地的 CI 流程来确保整体项目的基本质量（也就是下限），但是因为本地都是不可靠的。我们需要一个最终"裁判"来确定项目的质量，因此我们需要学习如何使用远程仓库的流水线来构建 CI 流程。

虽然 git 是一个分布式的协作方式，这里的分布式是指每个终端都可以独立运行。但是对于团队协作来说一定会有一个远程的中心点，比如 github/gitlab 等应用来作为中间交换节点，以统一项目的协作。因此，我们就可以将这些远程端作为“裁判”或者说“最终决策者”来帮我们做中立的判断。

而 github / gitlab 这些比较主流的 git 应用也是这么思考的，因此他们会配备现成的流水线来帮我们做这些事情。这些流水线的本质就是一个简单的容器空间，在里面我们可以检出代码、运行指令等等，然后流水线通过运行指令的返回值来判断这条流水线是不是通过。

当然了，除了内置的流水线以外还有一些第三方的流水线产品，比如 CircleCI 、Travis 等老牌的产品也是非常受欢迎的。不过我们还是以开源社区主流的 github 为例，不论其形态如何变化，需要了解的是他们的内核都是一样的，学会了一个就等于学会了所有。

简单示例

github 内置的流水线产品名为 github action ，只需要在 github 的仓库中创建一个 .github/workflows/<any>.yaml 文件即可， any 可以是任何你喜欢的名称。一个最简单的配置文件可能是这样的（来自官方文档的示例）：

name: GitHub Actions Demo

run-name: ${{ github.actor }} is testing out GitHub Actions 🚀

on: [push]

jobs:

Explore-GitHub-Actions:

runs-on: ubuntu-latest

steps:

- run: echo "🎉 The job was automatically triggered by a ${{ github.event_name }} event."

- run: echo "🐧 This job is now running on a ${{ runner.os }} server hosted by GitHub!"

- run: echo "🔎 The name of your branch is ${{ github.ref }} and your repository is ${{ github.repository }}."

- name: Check out repository code

uses: actions/checkout@v3

- run: echo "💡 The ${{ github.repository }} repository has been cloned to the runner."

- run: echo "🖥️ The workflow is now ready to test your code on the runner."

- name: List files in the repository

run: |

ls ${{ github.workspace }}

- run: echo "🍏 This job's status is ${{ job.status }}."

name 定义了这个 action 的名字
run-name 定义了本次显示的名称，使用了内置变量语法 ${{ github.actor }} 从 github action 的内置上下文中获取执行者的名称
on 是 action 的触发时机，push 表示在 commit 推送的时候会触发这个 action 。
jobs 表示要执行的任务，可以执行多个任务。
runs-on 表示要在什么环境下执行，示例是在 ubuntu 系统最新版环境下执行。
steps 表示要运行的步骤，run 表示直接执行 shell 命令，uses 表示使用其他人现成写好的 actions，如 actions/checkout@v3 就是官方提供的 action ，用于把源代码检出到当前环境目录下。

最简单的来说，我们只需要编写配置告知 github action 我们要执行的时机、环境、命令。那么每次触发时机的时候 github action 就会自动第一个独立的容器帮我们运行我们指定的命令，来实现做一些检查工作。

将 CI 流程搬到线上

那么通过以上的例子，我们可以很快了解到这些流水线的产品的内核逻辑无非就是面向过程的指令排列。既然清楚了这一点我们就可以将我们上一节讲的，在本地跑的检查命令丢到线上去执行。

首先我们回忆一下我们在本地要执行的命令：

eslint --fix

prettier --write

如果翻译成 Github Action 的描述就是

jobs:

CI:

runs-on: ubuntu-latest

steps:

- run: eslint

- run: prettier --check ./

注意当我们在持续集成阶段，我们只需要去判断是否正确，而不是去帮助用户去修改，以保证检查的纯粹性。当然，因为不需要修改，指令则需要进行一些修改。不同的工具可能会有不同指令形式，你可以通过查阅官方文档或者在终端输入相关的--help 命令来查询。几乎所有的命令行程序都会拥有一个 help 指令，如可以运行 prettier --help 来打印出prettier 的所有操作。

我们将这个工作命名为 CI ，顺便通过 runs-on 指定一下执行环境镜像，对于 node 程序来说在除了 window 以外的任何镜像上都是差不多的，但是考虑到 Linux 的开放性，大部分的流水线应用都会对 Linux 环境有很好的支持，因此建议选择主流的几个 Linux 发行版即可。

然后我们还需要补充一些信息，比如给这条流水线命个名字，定义一下触发时机。另外在之前因为是对源代码进行操作，因此还需要拉一下代码。

完整的 action 配置文件应该是这样的：

# .github/workflows/ci.yaml

name: CI

on: [push]

jobs:

CI:

runs-on: ubuntu-latest

steps:

- name: Check out repository code

uses: actions/checkout@v3

- name: Install Packages

run: npm install

- name: Check Lint

run: npx eslint

- name: Check Code Format

run: npx prettier --check ./

- name: Check Simple Build # 对项目直接编译做一次简单的打包操作，防止出现项目格式没有问题但是打包出现问题

run: npm run build

将这个配置文件添加到项目，然后推送代码到远程 Github 平台，就可以在 Action 标签中看到自动化检查运行的记录，在每次 commit 的记录中也可以看到表示通过的绿色对钩以及表示失败的红色叉号，如果是一个 pull request 请求，也会自动出现在检查清单中，帮助审阅者快速判断基本可用性。

以上为 facebook/react 项目的 ci 检查效果

总结

本节我们学习了如何使用 github action 来帮助我们构建一个简单的远程流水线。通过一个中心节点（Github）来帮助我们做一个唯一的裁判，判断一次提交是否能够达到代码质量的下限。

希望大家能够了解到，不管是什么平台，其内核本质是完全一样的，无非就是顺序执行预设好的命令，然后根据输出来判断是正确的还是错误的，以达到帮助开发者的目的。

下一节我们会学习如何来编写单元测试，通过单元测试来保证代码逻辑正确性。

【CICD】远程仓库CI流程的全部评论