行将开播：5月14日，Jenkins在K8S下的三种部署流程和实战演示

本文是 Nebula Graph 工程师应用 GitHub Action 搭建 CI/CD 系统的实际，希望可以对读者有所协助，同时也欢迎读者留言与作者停止交流。

1. 缘起

Nebula Graph 最早的自动化测试是运用搭建在 Azure 上的 Jenkins，配合着 GitHub 的 Webhook 完成的，在用户提交 Pull Request 时，加个 ready-for-testing 的 label 再评论一句 Jenkins go 就可以自动的运转相应的 UT 测试，效果如下：

由于是租用的 Azure 的云主机，加上 nebula 的编译要求的机器配置较高，而且义务的触发主要集中在白天。所以上述的方案性价比较低，从去年团队就在思索寻觅替代的方案，预备下线 Azure 上的测试机，并且还要能提供多环境的测试方案。

调研了一圈现有的产品主要有：

TravisCI

CircleCI

Azure Pipeline

Jenkins on k8s（自建）

虽然下面的产品对开源项目有些限制，但全体都还算比较友好。

鉴于之前 GitLab CI 的运用阅历，体会到假设能跟 GitHub 深度集成那当然是首选。所谓“深度”表示可以共享 GitHub 的整个开源的生态以及完美的 API 调用（后话）。恰巧 2019，GitHub Action 2.0 横空出生，Nebula Graph 便英勇的入了坑。

这里复杂概述一下我们在运用 GitHub Action 时体会到的优点：

收费。开源项目可以无偿运用 Action 的一切功用，而且机器配置较高。

开源生态好。在整个 CI 的流程里，可以直接运用 GitHub 上的一切开源的 Action，哪怕就是没有满足需求的 Action，本人上手写也不是很费事，而且还支持 docker 定制，用 bash 就可以完成一个专属的 Action。

支持多种系统。Windows、macOS 和 Linux 都可以一键运用，跨平台复杂方便。

可跟 GitHub 的 API 互动。经过 GITHUB_TOKEN 可以直接拜访 GitHub API V3，想上传文件，反省 PR 形状，运用 curl 命令即可完成。

自托管。只需提供 workflow 的描画文件，将其放置到 .github/workflows/ 目录下，每次提交便会自动触发执行新的 action run。

Workflow 描画文件改为 YAML 格式。目前的描画方式要比 Action 1.0 中的 workflow 文件愈加繁复易读。

下面在讲实际之前还是要先讲讲 Nebula Graph 的需求：首要目的比较明白就是自动化测试。

作为数据库产品，测试怎样强调也不为过。Nebula Graph 的测试主要分单元测试和集成测试。用 GitHub Action 其实主要瞄准的是单元测试，然后再给集成测试做些预备，比如 docker 镜像构建和安装顺序打包。顺带再处置一下 PM 小姐姐的发布需求，就整个构建起来了第一版的 CI/CD 流程。

2. PR 测试

Nebula Graph 作为托管在 GitHub 上的开源项目，首先要处置的测试成绩就是当贡献者提交了 PR 央求后，如何才能快速地停止变更验证？主要有以下几个方面。

符不契合编码标准；

能不能在不同系统上都编译经过；

单测有没有失败；

代码掩盖率有没有下降等。

只要上述的要求全部满足并且有至少两位 reviewer 的赞同，变更才能进入主干分支。

借助于 cpplint 或许 clang-format 等开源工具可以比较复杂地完成要求 1，假设此要求未经过验证，前面的步骤就自动跳过，不再继续执行。

关于要求 2，我们希望能同时在目前支持的几个系统上运转 Nebula 源码的编译验证。那么像之前在物理机上直接构建的方式就不再可取，毕竟一台物理机的价钱曾经昂扬，何况一台还不足够。为了保证编译环境的分歧性，还要尽能够的增加机器的功用损失，最终采用了 docker 的容器化构建方式。再借助 Action 的 matrix 运转策略 和对 docker 的支持，还算顺利地将整个流程走通。

运转的大约流程如上图所示，在 vesoft-inc/nebula-dev-docker 项目中维护 nebula 编译环境的 docker 镜像，当编译器或许 thirdparty 依赖晋级变更时，自动触发 docker hub 的 Build 义务（见下图）。当新的 Pull Request 提交以后，Action 便会被触发末尾拉取最新的编译环境镜像，执行编译。

针对 PR 的 workflow 残缺描画见文件 pull_request.yaml。同时，思索到并不是每团体提交的 PR 都需求立刻运转 CI 测试，且自建的机器资源有限，对 CI 的触发做了如下限制：

只要 lint 校验经过的 PR 才会将后续的 job 下发到自建的 runner，lint 的义务比较轻量，可以运用 GitHub Action 托管的机器来执行，无需占用线下的资源。

只要添加了 ready-for-testing  label 的 PR 才会触发 action 的执行，而 label 的添加有权限的控制。进一步优化 runner 被随意触发的状况。对 label 的限制如下所示：

jobs: 

  lint: 

    name: cpplint 

    if: contains(join(toJson(github.event.pull_request.labels.*.name)), 'ready-for-testing') 

在 PR 中执行完成后的效果如下所示：

(责任编辑：admin)