【问题标题】：Why is "continuous-integration/jenkins/pr-merge" not being triggered by GitHub on a pull request?为什么 GitHub 不会在拉取请求中触发“持续集成/jenkins/pr-merge”？
【发布时间】：2021-11-25 20:28:22
【问题描述】：

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

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

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

请注意，Project 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 -> 设置 -> Hooks -> Webhooks

GitHub 中的项目 A 有一个 webhook，配置如下：

有效载荷 URL https://jenkins.mycompany.com/github-webhook/
内容类型application/json
让我选择单个事件：拉取请求、推送、存储库被选中
活动：选中

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

CloudBees Jenkins 企业版

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

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

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

出了什么问题/遗漏了什么？

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

更新

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

【问题讨论】：

现在扫描存储库是否返回任何有用的日志？你能在 ProjectB 的 Jenkins 仪表板中看到分支和 PR 吗？ Jenkins 中 Project B 的配置是否使用与 ProjectA 相同的 GitHub API 端点？与 Jenkins 中使用的令牌关联的用户是否在 OrgA 和 OrgB 上都设置为所有者？
“扫描组织日志”只显示它处理每个单独的拉取请求，然后“完成：成功”——没有什么真正有用的。我在 ProjectA 或 ProjectB 的 Jenkins 仪表板中看不到分支或 PR。两个 Jenkins 项目都为 GitHub 使用相同的 API 端点。 Jenkins 中使用的帐户的用户不是 GitHub 中 OrgA 或 OrgB 的所有者。
好吧，这很奇怪..如果扫描成功，那么它们应该出现在仪表板中，但是在日志中它应该显示类似这样的内容正在获取远程分支...检查分支分支名称-a 'Jenkinsfile ' 找到符合标准...根据我的经验，Jenkins 中使用的帐户总是被指定为所有者，以便有权访问 repos 等，然后可以使用令牌范围（如 repo、admin :org_hook 等）
抱歉，我没找对地方，但我确实在 Jenkins 仪表板中看到了一个 Pull Requests 选项卡，其中显示了 PR。分支也有一个选项卡，但它显示零分支（ProjectA 和 ProjectB 都显示零分支）。日志还显示“正在检查拉取请求……正在获取远程拉取请求……正在检查拉取请求……找到‘ci-cd/ourscript.groovy’……符合标准……”
如果你想让Branches来展示你需要添加Behaviors Discover branches Strategy 所有分支。所以基本上 github 到 jenkins 之间的连接工作正常，但 jenkins 并没有只在 ProjectB/OrgB 上报告构建状态。您能否确认项目 B（可能还有 A）是否是公共/私有/内部的？

标签： github jenkins continuous-integration pipeline pull-request

【解决方案1】：

将我们在 cmets 中得到的分辨率作为答案发布。

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

组织与项目的区别

OrgA/ProjectA - 用户是组织 (OrgA) 的成员，还添加到 repo 的 Collaborators 部分，具有读取权限，以及一个团队，在 repo 本身 (ProjectA) 上有 写入权限。
OrgB/ProjectB - 用户是组织 (OrgB) 的成员，并且在 repo 本身 (ProjectB) 的协作者部分中，但具有 读取权限。

这导致 projectB 状态检查的问题没有使用来自构建的 Jenkins 信息填充：
continuous-integration/jenkins/pr-merge 缺少 GitHub 存储库的状态检查。

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

在这种情况下，我们要更新需要Write access level的github状态：

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

【讨论】：

再次感谢。用户不仅是组织的成员，而且还列在具有读取权限的相应存储库的协作者部分中。
欢迎（：我也更新了答案以指定这一点。
对于 ProjectA，用户也在 repo 的 Collaborators 部分具有读取权限。
当然我也添加了。我最初没有指定 Collaborators 部分，因为只能通过该部分将单个用户添加到任何 repo 中。但是现在明确指定它是很好的，以便更好地理解。