利用Jenkins完成Pre-MR的代码回归-白红宇

前言

Gitlab作为一个功能强大的代码管理系统被广泛应用，它的Merge Request（MR)机制已经在实践中被证明非常适合多人协同开发，一个MR里的代码可以被多人同时review，并在确认有效后由Master批准合入。在分支合并前，通常需要在本地进行合并测试，看是否有代码冲突，编译是否通过，没有问题了，才敢把合并后的代码往主干分支提交，但是如果一个代码分支很多怎么办？如果日常需要经常合并怎么办？如果有一个CI方案可以在服务器进行自动合并，执行校验程序并报告给GitLab，就能大大提高Master合并MR的信心，Master就可以把精力集中在业务内容本身上。

尽管GitLab也提供了CI方案来解决MR合并前的precheck工作，但gitlab-ci-runner采用的是push mode，对ci-server、 CI脚本的设置一般都比较固定，且不够直观易用。

Jenkins作为一个外部服务，能够借助插件感知Gitlab上的MR事件，以pull mode触发CI任务，比较灵活。

本文将介绍如何把Jenkins的CI job集成到MR precheck中，并做到可配置化。

业务场景

rds/dxxxxs是一个多人协作的python项目，主分支为develop，在开发者合并代码到develop分支前，需要对MR中的文件做lint检查，以确保符合PEP8代码标准并且没有Error，只有确认无语法错误的MR才可以接受合并。

Jenkins配置步骤

下载并配置Gitlab Merge Request Builder插件

在Jenkins -> Plugin Manager 的Available页里搜索并安装插件：

在Jenkins -> Manage Jenkins -> Configure System里找到Gitlab Merge Request Builder的配置项，如下图：

Jenkins Username: 使用同名Gitlab用户用于访问GitLab

Jenkins API Token: 见Gitlab用户-> profile setting -> Account 里的Private Token

Assignee Filter: 根据MR Assignee触发precheck

Label Filter: 根据MR Label触发Precheck

新建Job并配置

点击Jenkins -> New Item, 输入Job Name，创建一个Freestyle Job

在Source Code Management的git一项中配置监听源码路径、源分支、目标分支信息，如下图：

其中：

第一个Repositories -> Repo URL是项目代码，用作目标代码路径

${gitlabTargetBranch} : 要合并的目标代码分支，在本例中是develop或release/* 分支

${gitlabSourceRepository} : 要合并的代码源路径

${gitlabSourceBranch} : 要合并的代码源分支

以上这四个参数构成了CI job在本地环境所使用的代码源/目标配置信息。

配置Build Trigger

Gitlab Merge Request Builder的触发器配置见下图：

GitLab Project Path和Target Branch Regex指定了MR的来源和分支，建议勾选"Use HTTPs URL"选项来clone源码到本地。如果你的校验脚本足够完善，也可以利用Auto Close Failed或Auto Merge Passed选项来根据precheck的结果自动处置MR。

结合SCM和Build Trigger的配置不难看出， Gitlab Merge Request Builder本质上是一个用Jenkins作为代理，为Gitlab MR提供CI-runner和灵活的脚本配置的集成方案；在本例中，我们在测试环境里预完成一次本地Merge，然后对这个临时分支做合规检查。

配置校验脚本

结合前面的业务场景，对MR中涉及到的增量文件做lint纠错检查

你可以根据自己项目里具体的业务需求，调整对每个MR合并后的检查内容。

保存以上工作。等待下一次合并触发这个Jenkins Job

Merge Request触发precheck CI流程

打通Gitlab MR和Jenkins Job之后，你在项目的Merge Reuqest List 页面应该能看到每个MR所触发的precheck的结果，对勾的为通过，否则则需要检查具体CI job的报错信息。

在MR detail页面里，你会看到一个MR中，每次文件改动所触发的precheck结果，可以非常方便快速地告诉MR Requester 每次commit的内容是否满足precheck标准。

与此同时，在Jenkins Job的Build History里你也能看到每次MR的编号、源=>目标分支信息。如果你是PM，也可以通过这里的Build History trend分析过去一段时间里，团队提交的代码数量和质量的趋势。

后记

更多关于Gitlab Merge Request Builder的信息请移步：

你可以利用插件提供的环境变量做更加复杂的CI任务，或者根据自己的需要开发发布新的插件功能。

以上就是本次分享的内容，希望能够对使用gitlab的研发团队提高工程效率和迭代速度有所帮助。

Enjoy~！