六、配置github的pull request触发jenkins自动构建

　　之前的配置，都是向master分支push操作触发jenkins进行构建，但是在一般的正常工作中，不会允许程序员直接向主分支推送代码；正常都是fork一个本地的分支，在本地分支调试完后，向主干分支提交pull request，待相关的管理人员进行review后，才merge到master分支；

　　基于此，我们之前的配置就有点不合适了，接下来我们就一块研究下如何在别人提交pull request时，就自动触发构建，当然这个构建要执行的任务，应该是将新提交的代码获取到服务器，并部署到环境当中，这应该是一些基本的操作，不懂就问下别人你们的环境如何部署；这里我们主要看如何配置jenkins能使pull request触发构建；

第一步：安装pull request builder plugin插件

　　jenkins插件管理中，可选插件中搜索pull request builder plugin，选中后点击直接下载，插件安装完一般都需要重启jenkins以生效；

　　这个插件应该是最近版本新出的，因为网上的资料确实少，甚至有些文章说不需要特别的插件，只要勾选了Build when a change is pushed to GitHub，不管是push还是pull request都能触发jenkins构建，这应该是不靠谱的；

　　pull request builder plugin插件官方文档：https://github.com/jenkinsci/ghprb-plugin/blob/master/README.md

第二步：配置pull request builder plugin插件

　　安装好插件以后，jenkins》》系统管理》》系统设置》》GitHub Pull Request Builder节点：

　　

　　GitHub Server API URL：　　如果不是使用的企业版jenkins，就保持默认的https://api.github.com；

　　Jenkins URL overrde：　　如果考虑到防火墙、跨域等问题，可以写一个替换连接jenkins主页的url；

　　Shared secret：　　如果填写一个密码，则每一个提交的pull request都需要验证这个密码才能连接jenkins；

　　Credentials：　　选择我们之前用github生成的token创建的认证身份；一般这个身份在github中具有较高的权限；

　　完后点击下方的测试链接，来测试jenkins与github的基本连接以及身份用户的权限验证；

　　

　　其中Repository ownere/name，顾名思义就是填写github的用户名跟远程库名，中间有反斜杠/；

　　在Description写一个这个Credentials的描述，以区分将来不同Credentials；

　　

　　下面Admin list中填写github用户白名单，在白名单中的用户提交pull request，可以直接触发构建，没有在白名单中的，需要通过admin的确认；感受下官网的描述：

　　When a new pull request is opened in the project and the author of the pull request isn't whitelisted, builder will ask Can one of the admins verify this patch?. One of the admins can comment ok to test to accept this pull request for testing, test this please for one time test run and add to whitelist to add the author to the whitelist.

　　If an author of a pull request is whitelisted, adding a new pull request or new commit to an existing pull request will start a new build.

　　ok，配置完后点击保存；

第三步：配置jenkins任务

　　基本的配置跟之前的类似，我这里只提不同的地方：

　　1、源码管理

　　

　　基本配置搞定后，点击高级：

　　Name填写origin

　　Refspec填写　　+refs/pull/*:refs/remotes/origin/pr/*

　　Branch Specifier填写${sha1}，如果想要用到提交的pr，则这个地方填写${ghprbActualCommit}

　　官网描述：

• Under Advanced, set Name to origin and:
  • If you just want to build PRs, set refspec to +refs/pull/*:refs/remotes/origin/pr/*
  • If you want to build PRs and branches, set refspec to +refs/heads/*:refs/remotes/origin/* +refs/pull/*:refs/remotes/origin/pr/* (see note below about parameterized builds)
• In Branch Specifier, enter ${sha1} instead of the default */master.
• If you want to use the actual commit in the pull request, use ${ghprbActualCommit} instead of ${sha1}

　　2、构建触发器

　　

　　如果插件安装正常，构建触发器这边会有GitHub Pull Request Builder，不要选择之前的push触发的那个咯；下面的credentials选择下拉框给出的就好，应该就是之前在系统设置中测试通过的那个；

　　Admin list填写对于这个job要加入白名单的github用户；下面的Use github hooks for build triggering勾选；

　　3、构建步骤

　　

　　如上截图，在构建操作中，我设置了两个Execute shell用以区分构建操作的两个步骤；第一个是在提交pr，并将pr拉取下来merge到jenkins工作目录中配置的代码分支后，执行环境部署的操作，这里请根据你们项目中实际的操作进行配置；第二个Execute shell是在部署好了新环境的基础上，执行postman的api脚本；只有在集成了新pr的环境中执行，才能对该pr进行测试，看是否会对整个环境的api稳定性造成什么影响；

　　另外如果配置的没有问题，在github对应的远程库，Settings>>Webhooks中，会生成一个新的webhook：

　　

　　要保证这个hook的触发方式是pull_request，如果不是，需要点击Edit进行修改：

　　

　　与Pull request相关的有三个，从名称上就可以看出，下面两个一个是对pr进行review时触发，另一个是对pr的review进行评论；根据需要进行配置，一般情况只要Pull request就可以，包括新建pr、关闭pr(目测不会触发)、编辑pr等等都会触发github想jenkins发送post请求，jenkins执行构建操作；

　　其他的跟之前的配置相同，这里就不啰嗦了，不懂得看我其他几篇文章吧；

　　

　　ok，到这里配置就完成了，保存一下提交一个pull request试试看吧；

　　github也是工作中比较常用的工具，这里没有出相关的学习资料，因为在下也是在工作中零零碎碎学习的，比较不系统╮(╯▽╰)╭；需要的话，大家可以在网上搜一下教程；