GitHub和Jenkins拉取请求检查

在我之前的文章GitHub和Jenkins集成中,我展示了将GitHub与Jenkins集成的一种可能方法,并概述了拉取请求检查的思想和流程。 在这篇文章中,我将向您展示如何配置Jenkins作业以实现这一目标,以及如何在整个过程中添加一些幻想。

詹金斯的职位设置

在我离开的地方接机,让我们创建一个简单的Jenkins作业,以演示整个拉取请求检查的想法。 由于Jenkins职位定义中可能会出现很多内容,因此让我们集中讨论此集成所需的内容,而忽略其余内容。 您需要做的第一件事是在GitHub项目字段中提供指向GitHub存储库的链接。 该URL遵循已建立的GitHub约定(并将在此配置中的其他地方使用) https://GITHUB_HOST:GITHUB_PORT/ORGANISATION/REPOSITORY 。 该字段位于作业配置页面顶部附近。

接下来重点介绍配置的“源代码管理”部分。 选择Git后,您可以从“凭证”选择和“存储库URL”指定开始。 如果您遵循上一篇文章的建议,请输入属于专门为自动化目的而创建的用户的凭据。 该URL应指向.git项目文件,其架构与上述项目URL略有不同,因此请不要将它们混在一起git@GITHUB_HOST:GITHUB_PORT/ORGANISATION/REPOSITORY.git

单击“高级”后,将显示一些附加规范。 这是至关重要的部分,因为它确定了作业执行期间要检出的内容。 需要将分支的名称设置为origin ,并按如下所示输入refspec表达式+refs/pull/*:refs/remotes/origin/pr/* 。 最后要提供的是分支说明符,然后选择您首选的存储库浏览器。 分支指定符的值由GitHub提供,可通过构建参数${sha1}

先进的源代码管理

该配置的最后一步是自定义GitHub Pull Request Builder插件的行为。 转到“构建触发器”部分,并确保列表中唯一选中的选项是GitHub Pull Request Builder。 不要忘了选中“使用github挂钩进行构建触发”,以便该插件正确接收从GitHub发送的事件。

基本触发

GitHub和Jenkins集成就是这样。 此时,您可以执行默认设置,因为默认设置效果很好。 如果您正在运行GitHub的本地实例,则可以考虑在“高级”部分中选中自动生成每个拉取请求,而无需询问(“危险!”)。 由于此选项允许任何人运行其代码,因此对于公共版本而言可能很危险。 如果您使用GitHub的本地实例,则可以立即进行拉取请求检查,从而使结果尽快可用,而无需管理员批准。

运行时看起来如何?

好吧,这当然是一个公平的问题,尤其是在完成所有配置工作之后。 这种集成的设计方式是使GitHub成为整个解决方案的前端,而Jenkins成为整个解决方案的后端。 考虑到它们各自的角色和能力,这很有意义。 话虽如此,但我们将重点放在GitHub上各种构建作业状态及其外观的表示上。

这种集成的UI和UX本质上是非常简约的(听起来更时髦,我敢称其为skeuomorphic),并且非常适合整个GitHub UI和工作流。 考虑以下来自拉取请求清单的照片:

GPRB插件图标

根据构建作业的状态,拉取请求右侧的图标会更改。 一旦事件被注册并发送,橙色/棕色圆圈将出现在拉取请求旁边。 基于构建的状态,失败或成功将在稍后的名称旁边显示。 该视图非常适合查看Jenkins中发生的事情(无需过滤掉正在运行的作业和计划的作业)。 单击拉取请求并滚动到页面底部后,您应该看到类似以下内容:

GPRB插件状态

本节不仅通过提供有关构建作业结果的信息来增强“合并按钮”原始框,还链接了构建作业本身。

要记住的一件事: 在创建拉取请求时,始终确保可以自动合并要推送的代码 。 这个过程非常简单,无法猜出您想如何解决合并冲突。 拉取最新版本的代码并手动解决代码中的冲突,可以让您从头再来,并确保构建作业将正确测试您的代码。 我不确定在合并代码发生冲突的情况下实际构建了什么,我也不想知道。 无论此集成如何,都将这一步骤作为工作流程的一部分是有意义的,因此,我将不再赘述。

建立触发器

关于如何触发此质量保证机制的方法,您有三个选择:

  • 创建一个新的拉取请求(通过GitHub)
  • 将新更改推送到现有的拉取请求(通过git)
  • 使用手动触发
    • 这是一个很好的功能,允许您选择自定义短语(具有regexp匹配功能),该短语可用于对请求请求进行注释,从而生成计划的Jenkins构建。

进一步定制

一旦完成了简单的构建工作并开始运行,我们就可以开始考虑对该过程进行进一步的自定义。 即使您可以在这方面做很多事情,我还是建议您尽可能地坚持简单的解决方案。 但是,情况并非总是如此,因此让我们介绍一些基本的自定义选项,以防我们的CI设置需要比简单的构建作业更复杂的解决方案:

  • 建立参数化
  • 有条件的构建步骤
  • 脚本和API

建立参数化

每当GitHub中发生有趣的事情时,我们在上一篇文章中设置的基于插件的集成都会让Jenkins知道。 可以期望这种集成由GitHub的Web Hook机制处理。 我正在谈论的这些有趣的事件之一肯定是pullrequestevent事件。 但是,如果您查看所述事件的有效负载 ,则必须滚动一段时间才能看到其所有荣耀。 幸运的是,GitHub Pull Request Builder插件可以过滤掉其中的许多属性,从而使Web挂钩提供的信息更易于访问和浏览。

给定您的GitHub实例注册了一个事件(例如创建请求请求),它将触发Web钩子。 Jenkins拾取了该Web挂钩,并且Jenkins调度了一个构建作业,并注入了所有必要的信息作为构建参数。 您可能已经注意到,我在配置的前面使用了许多可用的构建参数之一。 构建参数是Jenkins作业和管道的基本属性之一。 它们使CI工程师可以将信息和数据从一项作业传递到另一项作业,或者根据提供的值自定义作业的行为。

如果您想知道有什么用,请检查以下列表,其中显示了示例构建参数:

sha1=origin/pr/378/merge
ghprbActualCommit=3357460473a4ea60d338dd5f03d231294ba79f89
ghprbActualCommitAuthor=jakub
ghprbActualCommitAuthorEmail= jakub@email.com
ghprbTriggerAuthor=Jakub Staš
ghprbTriggerAuthorEmail=jakub@email.com
ghprbPullId=378
ghprbTargetBranch=feature/PROJ-123-Do-something
ghprbSourceBranch=task/PROJ-123-Do-a-part-of-it
ghprbPullAuthorEmail=jakub@email.com
ghprbPullDescription=GitHub pull request #378 of commit 3357460473a4ea60d338dd5f03d231294ba79f89 automatically merged.
ghprbPullTitle=Task/proj 123 do a part of it
ghprbPullLink=https://GITHUB_HOST:GITHUB_PORT/api/v3/repos/ORGANISATION/REPOSITORY/pulls/378
GIT_BRANCH=task/PROJ-123-Do-a-part-of-it

有条件的构建步骤

构建参数化的一大用途是利用条件构建步骤。 典型的情况是您要基于目标分支(构建参数ghprbTargetBranch )应用不同的测试服。 在玩了一段时间后,我最终根据以下分支使用了以下设置,即哪个分支是请求请求的目标分支:

  • feature分支
    • 运行单元测试和代码质量分析
  • develop分支
    • 运行单元测试,集成测试和用户验收测试
  • master分支
    • 运行所有检查

条件构建步骤插件提供了条件构建步骤功能。

脚本和API

绝对值得一试的最后一个自定义选项是GitHub自己的API和从Jenkins调用它的功能。 根据我自己的经验,注释和标签是GitHub提供的出色工具,用于支持和推动开发过程。 当您的构建工作需要很长时间才能完成,或者您想改善代码检查过程时,这将非常有用。

如果构建作业或管道运行较长时间,则能够大致了解正在发生的情况很有用。 在这里,您可以使用简单的Shell脚本,该脚本可以在执行过程中对pull请求本身进行注释。 这样,对给定的请求请求感兴趣的用户将得到通知,并可以采取行动。 您的注释脚本可以像这样简单(如果您决定使用它,请用适当的值替换所有大写的单词):

脚本参数:

  1. ghprbPullId –拉取请求的ID
  2. 要添加的评论
#!/bin/bash

payload+="{\"body\":\""
payload+=$2
payload+="\"}"

curl -k -H "Authorization: token OATH_TOKEN" -H "Content-Type: application/json" -d "$payload" https://GITHUB_HOST:GITHUB_PORT/api/v3/repos/ORGANISATION/REPOSITORY/issues/$1/comments

在代码审查过程中,我的经验表明,让Jenkins在提交代码审查之前先检查代码会更有效。 由于Jenkins之前已经检查了语法,格式和样式,因此审阅者可以将精力集中在业务逻辑上。 由于需要从拉取请求列表中访问此信息,因此我强烈建议在这种情况下使用GitHubs标签,因为它们提供了对内容进行分类的好方法,并且易于识别。 分配这种标签的脚本可以像这样简单:

脚本参数:

  1. ghprbPullId –拉取请求的ID
  2. 要添加的标签
#!/bin/bash

payload='["'
payload+=$2
payload+='"]'

curl -k -H "Authorization: token OATH_TOKEN" -H "Content-Type: application/json" -d $payload https://GITHUB_HOST:GITHUB_PORT/api/v3/repos/ORGANISATION/REPOSITORY/issues/$1/labels

这些脚本非常易于使用,并允许您向GitHub用户提供有用的信息。 您可以走得更远,使您的评论更加精彩。 添加一些视觉效果或链接您的日志和测试报告。 下面是一个简单的示例,说明您愿意尝试一下它的外观:

github评论

结论

所有事物都认为使用这些系统非常有趣。 这两个系统都极大地简化了开发人员的生活,并且这种小的改进使事情变得更加舒适。 当涉及到此集成的结果时,在我的工作场所中部署并启动了此最终版本后,这些时刻非常明显。 如果您拥有这些工具,建议您尝试这样的方法,并以同样的方式查看它是否适合您的团队。 祝一切顺利! :)

翻译自: https://www.javacodegeeks.com/2015/04/github-and-jenkins-pull-request-checking.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值