执行摘要
本次PR优化了CI重跑逻辑，针对包含sgl-kernel变更的PR，当使用/rerun-failed-ci命令时，通过检查sgl-kernel-build-wheels任务是否已为当前提交成功构建，来决定是进行全量重跑还是仅重跑失败任务。这避免了不必要的全量测试触发，特别是减少了不稳定测试（如MMLU TorchAO测试）导致的无限循环，提升了CI效率和开发体验。变更范围小，风险可控，已合并到主分支。
功能与动机
为什么做：原逻辑在PR有sgl-kernel变更时，使用/rerun-failed-ci会强制全量重跑以确保内核轮子重新构建。但如果轮子已构建成功，全量重跑会重新触发所有测试，包括不稳定的测试（如PR body中提到的"MMLU TorchAO test that fluctuates at the 0.63 boundary"），导致测试随机失败并触发另一次全量重跑，形成无限循环。
要解决的问题：避免不必要的全量重跑，减少资源浪费和不稳定测试的影响，提升CI效率。
实现拆解
修改集中在scripts/ci/utils/slash_command_handler.py文件的handle_rerun_failed_ci函数中：
-
逻辑调整：
- 原代码：检测到sgl-kernel变更时，直接使用
rerun()进行全量重跑。
- 新代码：检测到sgl-kernel变更时，先检查当前提交的GitHub check runs中
sgl-kernel-build-wheels任务是否已成功。
-
关键代码块：
python
kernel_wheel_built = False
if sgl_kernel_changes:
try:
check_runs = gh_repo.get_commit(head_sha).get_check_runs()
for cr in check_runs:
if "sgl-kernel-build-wheels" in cr.name and cr.conclusion == "success":
kernel_wheel_built = True
print(f"sgl-kernel-build-wheels already passed (check run {cr.id}) - using rerun_failed_jobs")
break
if not kernel_wheel_built:
print("sgl-kernel-build-wheels has not passed yet - will use full rerun")
except Exception as e:
print(f"Failed to check sgl-kernel-build-wheels status: {e} - falling back to full rerun")
-
条件判断更新：在重跑失败工作流时，条件从if sgl_kernel_changes:改为if sgl_kernel_changes and not kernel_wheel_built:，确保仅当轮子未构建时才全量重跑。
评论区精华
review中仅有一条实质性讨论，由gemini-code-assist[bot]提出：
"The API call to get_check_runs() is not wrapped in a try-except block. If this call fails due to network issues, GitHub API downtime, or rate limiting, the entire slash command handler will crash without providing feedback to the user."
讨论要点：强调了异常处理的重要性，确保在API调用失败时脚本能优雅回退。作者jasperjiaguo回复"done"，并在最终代码中添加了try-except块，失败时回退到全量重跑，保证了鲁棒性。
风险与影响
技术风险：
- 新增的GitHub API调用可能因网络问题或速率限制失败，但已通过try-except处理，失败时回退到安全默认行为（全量重跑）。
- 逻辑依赖
sgl-kernel-build-wheels检查运行的准确命名和状态，如果任务名称变更或状态报告延迟/错误，可能导致误判（例如轮子已构建但被误认为未构建，触发不必要全量重跑）。
影响评估：
- 正面影响：减少CI资源消耗，加快重跑速度，降低不稳定测试的干扰。
- 影响范围：仅影响使用
/rerun-failed-ci命令且PR包含sgl-kernel变更的场景，不影响其他CI功能或生产代码。
- 兼容性：保持向后兼容，因为失败时回退到原逻辑。
关联脉络
从近期历史PR分析看，本PR属于CI基础设施优化系列的一部分：
- PR #22733 为GB200夜间流水线添加手动触发和环境门控，保护共享集群资源。
- PR #22727 回滚CUDA版本升级以解决内核测试问题。
- PR #22653 移除Dockerfile中失效的缓存复制指令，修复CI构建失败。
共同趋势：这些PR都关注CI的稳定性、效率和资源管理，反映了团队在持续改进CI/CD流水线，以减少维护负担并提升开发体验。本PR通过智能检查优化重跑逻辑，是这一趋势的具体体现。
参与讨论