前言
目前做到的效果是：在Github提Pull requests时，自动触发Jenkins执行单元测试，并将执行结果反馈给Github Pull requests页。
Unit Test CI 配置流程：
1 CI/CD
1.1 什么是 CI
** 持续集成（CI）：**是持续在源代码变更后自动检测、拉取、构建和单元测试的过程。
** 持续集成的目标：**是快速确保开发人员新提交的代码变更是正确的、可以被集成的，并且适合在代码库中进一步使用。
注：持续集成伴生的行为是持续测试。
1.2 什么是 CD
** 持续交付（CD）：**可自动将已验证的代码发布到存储库。
** 持续交付的目标：**是拥有一个可随时部署到生产环境的代码库。
** 持续部署（CD）：**可自动将应用发布到生产环境。
注：持续交付和持续部署，是持续通过自动化Pipeline的方式，发布制品到使用环境中的行为。这两个有时会交叉使用，没必要纠结于这些语义。
1.3 CI/CD 流程
** CI/CD流程：**又称为CI/CD流水线，持续交付流水线。
持续交付涵盖了从需求、设计、开发、构建、测试、上线整个过程的流程、工具、方法、平台化的输入以输出。
2 CI 平台选择
从2018年10月 Github Actions 出现后，很多文章讨论CI的平台选择，是Github Actions，还是Jenkins。
2.1 Github Actions
Github Actions是一个事件驱动（Push，Pull requests等）的持续集成和持续交付工具，可让您自动化构建、测试和部署应用程序到各种环境的过程。
换句话说，GitHub 把CI/CD的很多操作，比如抓取代码、运行测试等，叫做Actions。开发者可以自己写action，也可使用其他开发者提供的action，那么整个CI/CD过程，就变成了多个 actions 的组合，这就是Github Actions。
2.2 Jenkins
Jenkins 是一个用 Java 编写的开源自动化服务器，用于自动化持续构建、测试和部署软件项目的工作流。
Jenkins主要通过丰富的插件来实现CI/CD，下图代表一个简单的 Jenkins 工作流，它从 Github 中提取代码，从代码中构建一个 docker 镜像，然后对其进行测试并进一步推送到远程存储库 DockerHub。
2.3 Github Actions Vs Jenkins
Jenkins 和 GitHub Actions 都可创建能自动构建、测试、发布、发行和部署代码的工作流程。一般对多数的公司来说，不需要自己研发一个 CI 平台，而且工具之间并没有绝对的差异优势，这里只是客观阐述这两者的关联与异同。
2.3.1 Github Actions 的优势
易于使用： Github Actions 对初学者非常友好。您只需一个 YAML 文件即可开始使用。对于初创公司/小型公司，您的开发人员可能已经对 YAML 有所了解，因此 Github Actions 作为 CI/CD 平台是一个合乎逻辑的选择。
设置和维护：使用 Jenkins，您将在自定义服务器上运行它。这意味着您必须持续维护 Jenkins 服务器。但是，Github Actions 为您提供了可用于执行 CI/CD 操作的免费运行器。这些运行器由 Github 拥有和维护，但您也可以添加自托管运行器。
2.3.2 Github Action 的缺点
锁定：使用 Github Actions，您或多或少地与 Github 作为源代码管理系统联系在一起。使用 Jenkins 允许您将代码存储在 Github、Gitlab、BitBucket 等的任何存储库中。
成熟度： Jenkins 已经存在并且比 Github Actions 更成熟。Github 操作相对较新，因此社区支持较少。
2.3.3 Jenkins 的优势
使用 Jenkins 的优点之一是它是开源和免费的，不像其对应的 Github Actions 是“免费增值”。
插件可用于支持缓存，其中来自先前构建的文件被缓存并在需要时在新构建中重新实现。
2.3.4 Jenkins 的缺点
Jenkins 有很多插件提供给用户，不幸的是，其中一些插件并没有被开发人员经常维护。因此有必要在使用前检查插件是否支持正确。
它高度依赖插件，有时很难找到插件的基本功能。
您必须自己维护和管理 Jenkins 基础架构。
由于服务器上负载的不确定性，在远程（云）服务器上管理Jenkins的成本可能无法预测。这些负载包括代码量、人工制品量、提交次数等。
2.3.5 相似之处
Jenkins 使用 Declarative Pepeline 创建工作流程，这些工作流程类似于 GitHub Actions 工作流程文件。
Jenkins 使用阶段运行步骤集合，而 GitHub Actions 则使用作业来分组一个或多个步骤或单个命令。
Jenkins 和 GitHub Actions 支持基于容器的构建。
步骤或任务可以重复使用并与社区共享。
2.3.6 主要差异
Jenkins 有两种类型的语法用来创建管道：Declarative Pipeline 和 Scripted Pipeline。 GitHub Actions 使用 YAML 创建工作流程和配置文件。
Jenkins 部署通常是自托管的，用户在自己的数据中心维护服务器。 GitHub Actions 通过托管自己可用于运行作业的运行器提供混合云方法，同时也支持自托管运行器。
Github Actions vs Jenkins：进一步的比较如下表所示：
GitOps 是使用源版本控制平台 Git 管理基础架构和配置的实践。
异步集成仅意味着同时执行构建，从而使工作流程更快。至于 Jenkins，同步构建是主要内容。
Ad Hoc Workflow：对于在 Github Actions 中发生的构建，它会监视 git 事件触发器。另一方面，Jenkins 可以执行许多作业，例如：运行 bash 脚本、maven buildsm powershell 等。如果您需要运行作业以按顺序定期运行而不链接到代码库，那么 Jenkins 能够做到这一点。
2.4 小结
基于Jenkins的成熟性，以及工程编译Unity的复杂性，我们最终选择的Jenkins作为CI/CD的工具。
3 Unit Test CI（单元测试持续集成）
** 目前做到的效果是：在Github提Pull requests时，自动触发Jenkins执行单元测试，并将执行结果反馈给Github Pull requests页。**
下面主要详细阐述使用**GitHub pull request时Jenkins自动构建**的配置过程，对于Jenkins环境的搭建和配置，此处就不赘述了。
3.1 Github 生成 token
GitHub上点击个人头像，依次选择Settings > Developer settings > Personal access tokens， 点击Generate new token按钮进入新Token生成页面，勾选如图选项，点Generate token按钮生成Token并将生成的Token复制保存。
3.2 Jenkins 安装/配置 GitHub Pull Request Builder 插件
1、Jenkins > 系统管理 > 插件管理 > 可选插件，搜索GitHub Pull Request Builder，然后选择直接安装 
2、在Jenkins中添加Credentials，Kind处选择Secret text, Secret处填写GitHub的Token，后面配置GitHub Pull Request Builder时需要用到它。
3、然后再使用GitHub的用户名和密码创建另一个Credentials，后面配置任务的时候会用到。当然如果你已经添加过了，就不用再配置。
4、然后在 jenkins > 系统管理 > 系统设置 > GitHub Pull Request Builder如下配置
GitHub Server API URL: 默认为 https://api.github.com , 企业版填写 https://域名/api/v3/。
Credentials: 选择之前用GitHub生成的token创建的Credentials。
填好上面的内容后，可以通过下方的Connect to API 按钮验证连接GitHub是否正常，Check repo permissions按钮验证权限。
3.3 Jenkins 配置任务
3.3.1 新建任务
1、新建一个自由风格的任务，然后配置该任务
2、将项目的GitHub URL添加到GitHub 项目处(可以输入到浏览器中的项目)
3.3.2 源码管理
在配置源码管理中添加代码在GitHub中的地址，Credentials处选择上面用GItHub的账号和密码创建的Credentials。
Refspec：- 如果只想构建PR，请将refspec设置为+refs/pull/${ghprbPullId}/:refs/remotes/origin/pr/${ghprbPullId}/- 如果你想构建PR和分支，请将refspec设置为 +refs/heads/:refs/remotes/origin/ +refs/pull/${ghprbPullId}/:refs/remotes/origin/pr/${ghprbPullId}/
指定分支: 填写 ${sha1}, 如果想要用到提交的pr，则这个地方填写 ${ghprbActualCommit}
3.3.3 构建触发器
在构建触发器中添加管理员名单，勾选Use github hooks for build triggering并点击后面的高级按钮，White list中添加针对这个任务允许进行pull request的GitHub用户账号。
3.3.4 构建步骤
1、构建这里根据自己的项目情况选择合适的构建工具，我的项目使用Gradle构建的所以选择的是Invoke Gradle script。
2、如果添加了Set build status to “pending” on GitHub commit这个构建步骤，那么在构建的时候GItHub项目的Pull requests中会显示pending状态。
3.4 Github 新建webhook
1、在GitHub对应的项目远程仓库，Settings > Webhooks中，新建一个webhook, 按下图填写Jenkins地址。
2、选中Let me select individual events，勾选Pull requests选项。
3、如果GitHub能够正确连接Jenkins，那么Recent Deliveries下面会有一条没有报错的记录。
4、到此，配置就完成了。下面往项目的某个分支发一个pull request测试。发PR后GitHub上显示pending check状态
5、Jenkins上成功触发了一次构建
6、当成功构建后，GitHub上面的状态修改成successful checks。
3.5 后续改进
Github单测结果可视化
Github单测结果失败或异常时，不允许PR
Github支持跳转Jenkins具体构建任务
...
3.6 改进
Github支持跳转Jenkins具体构建任务：
4 鸣谢
【什么是 CI/CD？一文带你理解CI持续集成和CD持续交付/部署 - 红帽】
【faun.pub】
【GitHub pull request时Jenkins自动构建教程】
版权归原作者 Swuagg 所有， 如有侵权，请联系我们删除。