github - 为什么 GitHub 不会在拉取请求中触发“持续集成/jenkins/pr-merge”？

Question

在 GitHub Enterprise 中，我们在组织 A 下有项目 A。当我向项目 A 提交 PR（拉取请求）时，continuous-integration/jenkins/pr-merge会触发运行 Jenkins 管道以构建代码并执行单元测试。如果单元测试失败，这允许我们防止 PR 被合并到 master 中。

例如，这是我在 GitHub 中项目 A 的 PR 中看到的，其中包含一个损坏的单元测试：

现在我正在尝试将组织 B 下的项目 B 配置为相同的行为方式。但是，它不起作用。这是我在 GitHub 的项目 B 的 PR 中看到的，其中包括一个损坏的单元测试：

请注意，项目 B 的 PR 并未启动continuous-integration/jenkins/pr-merge.

项目A和项目B的配置

GitHub -> 设置 -> 分支 -> 分支保护规则

GitHub 中的项目 A 有一个分支保护规则master，只启用了一个设置：

• 合并前需要拉取请求审查

有趣的是，“合并前需要通过状态检查”设置未启用。出于好奇，我启用了它（没有保存它）并注意到“continuous-integration/jenkins/pr-merge”作为一个选项出现在它的下方。

我将项目 B 配置为具有完全相同的分支保护规则master，仅启用“合并前需要拉取请求审查”。出于好奇，我启用了“合并前需要通过状态检查”（不保存），它甚至没有显示continuous-integration/jenkins/pr-merge为选项。它只是说“未找到状态检查。抱歉，我们在上周找不到此存储库的任何状态检查。”

GitHub -> 设置 -> 钩子 -> Webhooks

GitHub 中的项目 A 有一个配置有以下内容的 webhook：

• 有效载荷 URLhttps://jenkins.mycompany.com/github-webhook/
• 内容类型application/json
• 让我选择单个事件：检查拉取请求、推送、存储库
• 活跃：勾选

我为项目 B 创建了一个具有完全相同设置的 webhook。在我为项目 B 提交 PR 后，我在项目 B 的 webhook 的“最近交付”下看到了一些带有绿色复选标记和“200”响应代码的项目，所以我认为它配置正确。

CloudBees 詹金斯企业

在 Jenkins Enterprise 中，项目 A 的管道属于“GitHub 组织”类型，并具有以下设置：

• API 端点：kubernetes-cbs-automation ( https://git.mycompany.com/api/v3 )
• 凭证：[特定于项目 A 的凭证]
• Owner：【项目 A 的 GitHub 组织】
• 行为：存储库：按名称过滤（使用正则表达式）：正则表达式：[项目 A 的 GitHub 存储库的名称]
• 行为：在存储库内：发现来自源的拉取请求：策略：将拉取请求与当前目标分支修订合并
• 项目识别器：管道 Jenkinsfile：脚本路径：ci-cd/jenkins/ProjectA-pipeline.groovy
• 属性策略：所有分支获得相同的属性
• 扫描组织触发器：选中“如果不运行，则定期运行”：间隔：1 天
• 孤立项目策略：选中“丢弃旧项目”
• 儿童孤儿物品策略：策略：继承
• 子扫描触发器：选中“如果不运行，则定期运行”：间隔：1 天
• 自动分支项目触发：要自动构建的分支名称：.*

我在 Jenkins Enterprise 中的“GitHub 组织”类型的项目 B 下创建了一个具有相同设置的项目（除了项目 A 特定的任何设置都替换为适当的项目 B 特定设置）。

有什么问题/遗漏？

鉴于项目 B 的 GitHub PR 无法启动continuous-integration/jenkins/pr-merge，看来我缺少一些配置。不幸的是，我们的 GitHub/Jenkins 管理员无法找出问题所在。

更新

我们已经确认项目 B 在提交 PR 时实际上是在 Jenkins 代理上启动构建。问题是 GitHub 没有continuous-integration/jenkins/pr-merge在 PR 的网页上显示。我们需要这样才能在构建失败时阻止 PR，同时我们也可以快速查看出了什么问题。

标签： githubjenkinscontinuous-integrationpipelinepull-request

Answer 1

发布我们在评论中得到的解决方案作为答案。

问题是在 Jenkins 中使用令牌的用户没有正确的访问权限级别来发布存储库上的状态检查。

组织和项目之间的差异

• OrgA/ProjectA - 用户是组织 (OrgA) 的成员，也添加到具有读取访问权限的存储库的协作者部分，以及对存储库本身 (ProjectA)具有写入访问权限的团队成员。
• OrgB/ProjectB - 用户是组织 (OrgB) 的成员，并且在 repo 本身 (ProjectB) 的协作者部分中，但具有读取访问权限。

这导致 projectB 状态检查的问题未使用构建中的 Jenkins 信息填充：
continuous-integration/jenkins/pr-mergeGitHub 存储库的状态检查中缺失。

摘要：
在 GitHub 和 Jenkins 之间建立连接时，我们需要为令牌的用户持有者提供所需的访问权限。

在这种情况下，我们要更新需要写入访问级别的 github 状态：

用户的令牌应该有范围repo:status