Jenkins对Gitlab merge requests进行代码检查

引子

当前大部分公司的代码管理业务流使用merge requests方式，当功能开发完成之后由开发发起merge requests将代码合入主干分支。

Jenkins的SCM可以监控git某个分支的状态，如果分支上有新的代码上传则可以触发任务。

用此种方式如果任务失败执行失败，开发修改代码之后需要再次去提交merge请求。如果我们能在merge请求时候触发Jenkins任务则可以大大减少这种情况。

此文介绍使用Jenkins的Gitlab插件和Gitlab的Webhook在merge请求中触发Jenkins任务（代码静态检查）并在请求中备注状态的一种实践。

前提环境

Jenkins中配置Gitlab权限，该用户权限需要为Developer或Maintainer。其他权限不能上传pipline状态（该权限可单独设置，可找管理员确认）。
Jenkins中创建freestyle任务（pipeline官方插件提示git merge支持不完整）
输入git地址，如：git@your.gitlab.server:gitlab_group/gitlab_project.git，在高级设置中输入Name为origin，Refspec为+refs/heads/:refs/remotes/origin/ +refs/merge-requests//head:refs/remotes/origin/merge-requests/
设置Branch Specifier属性，如果项目为单一代码库工作流，输入origin/ ${gitlabSourceBranch}。为Fork代码工作流则输入merge-requests/$ {gitlabMergeRequestIid}
在附加选项中添加Merge before build，其中Name设置为origin，Branch to merge设置为${gitlabTargetBranch}
设置触发器为Build when a change is pushed to GitLab。选择触发事件为Opened merge requests和comments
去gitlab页面设置webhook，其中url在上述第六步会提示，token也在第六步高级选型里面生成的，去除SSL验证的勾选，保存并测试webhook可以正确发送
在build中添加静态代码检查工具，如现在项目用的Sonar（其配置自行上网搜索）
在构建后操作中添加Publish build status to GitLab，该功能可上传pipeline状态到gitlib。

确认Jenkins中使用的gitlib账户的权限，同时在项目设置中查看pipeline权限。

因为上述配置中添加了comment触发，可在merge请求中添加备注“jenkins please retry a build”再次触发构建。

需要登录账户的权限为Maintainer。