GitHub和Jenkins拉取请求检查

最新推荐文章于 2023-02-23 13:50:54 发布

danpob13624

最新推荐文章于 2023-02-23 13:50:54 发布

阅读量380

点赞数

文章标签： python java git spring vue ViewUI

在我之前的文章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和工作流。考虑以下来自拉取请求清单的照片：

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

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

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

建立触发器

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

创建一个新的拉取请求（通过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请求本身进行注释。这样，对给定的请求请求感兴趣的用户将得到通知，并可以采取行动。您的注释脚本可以像这样简单（如果您决定使用它，请用适当的值替换所有大写的单词）：

脚本参数：

ghprbPullId –拉取请求的ID
要添加的评论

#!/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标签，因为它们提供了对内容进行分类的好方法，并且易于识别。分配这种标签的脚本可以像这样简单：

脚本参数：

ghprbPullId –拉取请求的ID
要添加的标签

#!/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用户提供有用的信息。您可以走得更远，使您的评论更加精彩。添加一些视觉效果或链接您的日志和测试报告。下面是一个简单的示例，说明您愿意尝试一下它的外观：