logo标签列表

为什么GitHub在拉取请求上没有触发"continuous-integration/jenkins/pr-merge"？

githubjenkinscontinuous-integrationpipelinepull-request
3
在GitHub Enterprise中，我们有组织A下的项目A。当我向项目A提交PR（拉取请求）时，会触发continuous-integration/jenkins/pr-merge，该流水线运行Jenkins管道以构建代码并执行单元测试。这使我们能够防止单元测试失败的PR合并到主分支中。
例如，在GitHub上为包含破损单元测试的项目A的PR中，我看到以下内容： enter image description here 现在我正在尝试配置组织B下的项目B以同样的方式运作。然而，它没有起作用。在GitHub上为包含破损单元测试的项目B的PR中，我看到以下内容：

enter image description here

请注意，项目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，包括：

  • Payload URL：https://jenkins.mycompany.com/github-webhook/
  • 内容类型：application/json
  • 让我选择单独的事件：已选中Pull requests、Pushes和Repositories
  • 激活状态：已选中

我按照完全相同的设置为B项目创建了Webhook。在提交B项目的PR后，我在B项目的Webhook下看到了一些带有绿色勾号和“200”响应代码的“最近交付”的条目，因此我认为它已经正确配置。

CloudBees Jenkins Enterprise

在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项目特定设置）。

有什么问题/缺失吗？

鉴于Project B的GitHub PR无法启动continuous-integration/jenkins/pr-merge，似乎我遗漏了某些配置。不幸的是，我们的GitHub/Jenkins管理员还没有能够找出问题所在。 更新 我们已确认，当提交PR时，Project B实际上会在Jenkins代理上启动构建。问题在于GitHub在PR网页上没有显示continuous-integration/jenkins/pr-merge。我们需要它来阻止PR构建失败，并快速查看出错原因。
现在的扫描仓库返回了有用的日志吗？您能在ProjectB的Jenkins仪表板中看到分支和PR吗？Jenkins中Project B的配置是否使用与ProjectA相同的GitHub API端点？在Jenkins中使用的令牌关联的用户是否在OrgA和OrgB上都设置为所有者？ - Pamela Sarkisyan
“扫描组织日志”只显示它处理每个单独的拉取请求，然后显示“完成：成功” - 没有什么真正有用的信息。我在Jenkins仪表板中没有看到ProjectA或ProjectB的分支或PR。两个Jenkins项目都使用相同的GitHub API端点。Jenkins中使用的帐户的用户不是GitHub中OrgA或OrgB的所有者。 - pacoverflow
好的，这很奇怪...如果扫描成功，他们应该出现在仪表板上，但是在日志中应该像这样显示：获取远程分支...检查分支 branch-name-a 找到 'Jenkinsfile' 符合条件...根据我的经验，在Jenkins中使用的帐户总是被指定为所有者，以便对存储库等具有正确访问权限，然后可以使用令牌范围（如repo、admin:org_hook等）来限定访问级别。 - Pamela Sarkisyan
抱歉，我没有找对地方，但是我在Jenkins仪表板中看到了一个Pull Requests选项卡，显示了PRs。也有一个Branches选项卡，但它显示零个分支（ProjectA和ProjectB都显示零个分支）。此外，日志显示“正在检查pull-requests... 获取远程拉取请求... 检查拉取请求... 找到'ci-cd/ourscript.groovy'... 符合标准...” - pacoverflow
如果您想要显示分支，您需要添加Behaviours Discover branches Strategy All branches。因此，基本上github与jenkins之间的连接正常工作，但是jenkins仅在ProjectB / OrgB上未报告构建状态。请确认项目B（以及可能的A）是公共/私有/内部的。 - Pamela Sarkisyan
显示剩余6条评论
1个回答
3

在评论区得出的解决方案中，我们将其作为答案发布。

问题在于Jenkins中使用令牌的用户没有足够的权限在存储库上发布状态检查。

组织和项目之间的区别

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

这导致在projectB上无法用Jenkins的信息填充状态检查:
在GitHub存储库的状态检查中缺少continuous-integration/jenkins/pr-merge。

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

在本例中，我们想要更新github状态，这需要写入访问级别：

github permission level for status checks

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

再次感谢。这些用户不仅是组织的成员，而且还在各自存储库的协作者部分列出，并具有读取访问权限。 - pacoverflow
欢迎：我更新了答案以明确说明。 - Pamela Sarkisyan
对于ProjectA，用户还在仓库的协作者部分具有读取权限。 - pacoverflow
当然，我也添加了那个。一开始我没有指定协作者部分，因为将单个用户添加到任何存储库只能通过该部分完成...但现在明确指定可以更好地理解。 - Pamela Sarkisyan
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接