执行摘要

• 一句话：增强 CI 命令授权、通知与重试逻辑
• 推荐动作：值得精读。本 PR 展示了如何在 GitHub Actions 生态中安全地处理来自 fork 的批准事件，利用两阶段工作流和幂等性标记。对于需要实现类似 CI 命令控制的仓库有很强的参考价值。

功能与动机

现有的 CI 命令缺乏细粒度授权：任何拥有仓库 read 权限的用户都可以通过评论触发 CI 运行，造成资源浪费和安全风险。此外，/ci retry 会重试全量作业，不够灵活。PR 旨在使 CI 访问显式、可审查，并在整个 Buildkite 构建完成之前即可介入。引用 PR body：“Improve the /ci run and /ci retry workflow so CI access is explicit, reviewable, and useful before an entire Buildkite build finishes.”

实现拆解

1. 授权逻辑完善（.github/workflows/scripts/run_ci_command.py）：重写授权判断，区分写权限用户（admin/maintain/write）和无写权限用户。无写权限用户必须满足 ready 标签或被受信任用户批准（has_trusted_approval 检查 review decision 和 reviews）。添加常量 CI_AUTHORIZED_COMMENT_MARKER 用于幂等性标记。
2. 重试行为优化（.github/workflows/scripts/run_ci_command.py）：/ci retry 只选择 failed、timed_out 或 expired 状态的 job 进行重试；当新 commit 没有构建时，等待之前的构建完成再创建过滤构建。
3. 用户反馈改进：被拒绝的命令用 ❌ 前缀评论，被授权的用 ✅ 前缀；不添加 👎 反应；处理中添加 👀 反应，结束后添加 🚀。
4. 通知工作流（.github/workflows/notify-ci-authorized.yml）：新增工作流，在 ready 标签添加或批准记录后，向无写权限的作者发送通知评论，告知 CI 已可用。通过 CI_AUTHORIZED_COMMENT_MARKER 避免重复通知。
5. 安全的两阶段批准记录（.github/workflows/record-ci-approval.yml）：因为 pull_request_review 事件在 fork 的 PR 上是只读 token，所以通过一个只包含 echo 的工作流成功完成来触发 notify-ci-authorized 工作流（使用 workflow_run 触发器），确保通知代码只运行在默认分支，从不执行贡献者代码。
6. 测试配套（.github/workflows/scripts/test_run_ci_command.py）：新增 5 个测试用例覆盖写权限用户直接运行、非受信任批准不能运行、ready 标签通知一次、以及重试构建的选择。扩展 FakeGitHub 支持 list_issue_comments。

关键文件：

• .github/workflows/scripts/run_ci_command.py（模块 CI 脚本；类别 infra；类型 infrastructure；符号 list_issue_comments, is_already_handled, command_comment_marker, has_bot_comment_marker）: 核心脚本，包含授权判断、重试构建、幂等性检查、通知作者等关键逻辑
• .github/workflows/scripts/test_run_ci_command.py（模块 CI 测试；类别 test；类型 test-coverage；符号 list_issue_comments, test_write_reviewer_runs_ci_without_delegation, test_ci_retry_uses_latest_current_sha_build, test_untrusted_approval_cannot_launch_ci）: 测试覆盖新增授权逻辑、通知、重试行为，确保质量
• .github/workflows/notify-ci-authorized.yml（模块 CI 工作流；类别 infra；类型 infrastructure）: 新增工作流，处理 ready 标签或批准后的通知逻辑
• .github/workflows/record-ci-approval.yml（模块 CI 工作流；类别 infra；类型 infrastructure）: 作为两阶段通知的中介，安全记录批准状态

关键符号：list_issue_comments, is_already_handled, command_comment_marker, has_bot_comment_marker, notify_authorized

评论区精华

PR 没有实质性的 review 讨论。Claude Bot 评论提示需要手动审查。维护者 ywang96 直接批准合并，没有其他评论。

• 暂无高价值评论线程

风险与影响

• 风险：
  • 授权绕过风险：若 has_trusted_approval 逻辑有缺陷（例如 review decision 为 CHANGES_REQUESTED 时误判为批准），可能导致未授权用户运行 CI。需要确保逻辑正确处理 review 状态，只认可 APPROVED。 (run_ci_command.py)
  • 幂等性缺失风险：is_already_handled 依赖 reaction 和评论 marker，若 GitHub API 延迟或缓存，可能重复处理命令，导致重复构建或重复通知。（run_ci_command.py 中的 is_already_handled 和 has_bot_comment_marker）
  • 工作流触发条件：notify-ci-authorized.yml 的 workflow_run 触发器依赖 Record CI approval 成功，若该工作流失败（例如权限问题），通知不会发出。
  • 重试等待逻辑：当新 commit 没有构建时，/ci retry 会等待之前的构建，可能导致用户困惑：如果长时间等待，用户可能重复重试。
• 影响：
  • 贡献者：非写权限贡献者现在必须等待 ready 标签或批准才能运行 CI，避免了无心触发浪费。通知改善了体验。
  • 维护者：更精细的授权控制，减少 CI 队列堵塞。
  • 系统：Buildkite 构建更智能，重试只针对失败 job，减少资源消耗。
  • 影响程度：中等，仅限于 CI 触发流程，不影响模型推理或服务。
  • 向前兼容：旧的 /ci run 行为被完全取代，但所有已有权限的用户仍然可以直接使用。
  • 风险标记：幂等性依赖 reaction/marker 的及时性, 重试等待可能导致困惑, 两阶段工作流故障延迟通知

关联脉络

• PR #50318 [CI] Retry failed steps on new PR commits: 同属 CI 命令和重试逻辑改进方向，扩展了 /ci retry 能力