pr 下评论/check 触发ci, 执行成功。但是没有刷新门禁结果

[lzyprime]

问题描述

• pr 提交代码后，门禁ci 自动执行，但因为kernel-build 和 lava 环境问题，最终ci失败，门禁判定不允许合入代码。
• 修好 kernel 和 lava 环境后，评论区通过/check评论发起ci, 最终结果为成功。但是门禁状态没有刷新，仍然记录着上次失败时的ci和状态。导致仍然不允许合入代码
• /check, 发起的ci能通过，说明pr代码本身没有问题，是构建环境问题。但是通过评论发起的ci, 不会刷新到门禁状态中。

example:

• Improve PTDUMP and introduce new fields RVCK-Project/rvck#206

[lzyprime]

根因分析

• github pr 下方显示的门禁状态，只有在接收到pr相关事件触发ci时，才会更新。也就是 github.event == pull_request_target, type in [opened, synchronize, reopened]
  • pull_request_target 详细说明
  • 这些在项目的 .github/workflow/xxx.yaml 中声明了要响应哪些事件和类型。如 rvck-6.6
• pr 和 issue中添加评论，实际上事件都是 issue_comment
  • pull_request_comment-use-issue_comment 详细说明
  • 同样在.github.workflow/xxx.yaml中声明响应这种事件。
• 因此pr代码更新和评论区/check 虽然都能触发 ci 流水线，但是最下方显示的门禁是github自己的行为，只认 pull_request_target 这种类型的事件触发。会用最后一次事件的ci状态作为门禁当前状态。可以手动点击rerun, 重新执行最后一次ci

[lzyprime]

解决方案和问题

根据分析，需要发起pr 的 open (新建和打开pr), reopend(重新打开ci), synchronize (代码更新), 或者跳转到ci页面执行rerun all job。

方案1: 评论/check时通过接口调用rerun all job

• pr 下评论 /check 时，通过 gh 命令调起最后一次ci的 rerun

问题:

• gh 调起 rerun 需要依赖 RUN_ID, JOB_ID。可能需要求出最后一次ci 的runid, 或者通过状态标签去生成ci的永久链接
• doc re-run-workflows-and-jobs
• rerun 最大期限为30天，过期后任务无法再重新触发。

方案2: close 然后 reopend 当前 pr

• 当评论/check时，利用gh 命令，关闭重开一次当前ci, 这样会触发reopend事件，然后触发ci 构建

问题:

• pr 中会留下 关闭 重新开启的记录
• gh 需要高权限去操作pr

方案3: 尝试其他事件type, 或者人工点击rerun

• 除了现在正在监听的 opened, synchronize, reopened， 实际上还有其他事件可以监听，如label, review, assign 等相关事件
• 可以通过监听指定 label 的设置， 或者指定reviewer, 等发起ci
• 结合方案2， 评论区/check时 执行设置label 或 reviewer的过程。
• 所有事件:
  • assigned
  • unassigned
  • labeled
  • unlabeled
  • opened
  • edited
  • closed
  • reopened
  • synchronize
  • converted_to_draft
  • locked
  • unlocked
  • enqueued
  • dequeued
  • milestoned
  • demilestoned
  • ready_for_review
  • review_requested
  • review_request_removed
  • auto_merge_enabled
  • auto_merge_disabled

20260313 总结:

• 目前采用人工点击rerun all job的方式触发
• 方案3 是刚想出的方案，需要写个demo验证。