执行摘要

该PR为check-stage-health GitHub Action添加了lint检查失败快速失败机制，当独立的lint.yml工作流失败时，立即终止后续CI测试任务，避免资源浪费。通过使用checks.listForRef API跨工作流查询lint状态，解决了原有listJobsForWorkflowRun只能查看同一工作流内任务的限制。这是一个典型的CI基础设施优化，旨在提升CI执行效率和开发者反馈速度。

功能与动机

为什么做这个变更？ 根据PR body描述，主要目标是让PR测试任务在lint检查失败时快速失败（fast-fail）。当前check-stage-health动作只能检测同一工作流内的任务失败，而lint检查运行在独立的lint.yml工作流中，因此无法及时检测lint失败，导致后续测试任务继续执行，浪费CI资源。

关键表述引用：

"Add lint failure detection to the check-stage-health action so that PR test jobs fast-fail when the lint check (from the separate lint.yml workflow) has failed."

实现拆解

核心改动文件： .github/actions/check-stage-health/action.yml

主要修改点：

1. 描述更新：将description从"Fail fast if any job in the current workflow run has already failed. Auto-skips for scheduled runs."更新为"Fail fast if any job in the current workflow run has already failed, or if the lint check (from lint.yml) has failed. Auto-skips for scheduled runs."，明确新增功能。

2. lint状态检查逻辑：在JavaScript代码中添加了跨工作流查询lint状态的逻辑：

// Check lint status from the separate Lint workflow (lint.yml).
// listJobsForWorkflowRun only sees jobs within the SAME run, so we use
// checks.listForRef which queries by commit SHA across ALL workflows.
const ref = context.payload.pull_request?.head?.sha || context.sha;
const { data } = await github.rest.checks.listForRef({
  owner: context.repo.owner,
  repo: context.repo.repo,
  ref: ref,
  check_name: 'lint',
});
const lintRun = data.check_runs.find(
  cr => cr.app?.slug === 'github-actions'
);
if (lintRun?.status === 'completed' && lintRun?.conclusion === 'failure') {
  core.setFailed('Fast-fail: lint check failed');
  return;
}

设计要点：

• 使用checks.listForRef API按commit SHA查询所有工作流中的检查状态，而非局限于同一工作流。
• 通过check_name: 'lint'过滤出lint检查，并通过app?.slug === 'github-actions'确认是GitHub Actions运行。
• 当lint检查状态为completed且结论为failure时，调用core.setFailed终止执行。
• 保留了原有的跳过保护逻辑（定时运行、SKIP_STAGE_HEALTH_CHECK环境变量），确保向后兼容。

评论区精华

讨论概况： 该PR没有review评论（review_comments_count: 0），表明变更被直接接受或通过其他渠道验证。

测试验证： 从提交历史可以看出作者进行了自我测试：

1. 提交4040b742："test: intentional lint failure for fast-fail testing" - 故意引入lint错误以验证快速失败机制。
2. 提交5cd4cd31："revert test lint failure" - 回滚测试更改，恢复干净状态。

这展示了作者通过实际测试验证功能有效性的务实做法。

风险与影响

技术风险：

1. API依赖风险：实现依赖于GitHub API的checks.listForRef，如果API调用失败、超时或速率受限，可能影响check-stage-health的正常执行。
2. 配置敏感性：逻辑假设lint检查的名称为'lint'且由GitHub Actions运行，如果lint工作流配置变更（如重命名、使用其他CI工具），可能导致查询失败或误判。
3. 边缘情况处理：虽然保留了跳过保护逻辑，但新增的lint检查可能在特定场景下（如并发运行、状态同步延迟）产生意外行为。

影响评估：

• 正面影响：减少因lint错误导致的CI资源浪费，特别是对于资源密集型测试任务；开发者更快获得lint失败反馈，缩短修复周期。
• 影响范围：仅限于CI流程，不涉及核心业务逻辑；对现有CI流程的修改是增量式的，保留了原有跳过机制。

关联脉络

与历史PR的关系：

• PR 22395、22388、22308：同属CI基础设施优化类别，都关注提升CI效率和稳定性。本PR延续了这一趋势，通过快速失败机制减少不必要的测试执行。
• PR 22308：特别相关，因为它也涉及CI验证和预防性措施（通过pre-commit钩子防止CI中断），与本PR的"快速失败以减少浪费"理念一致。

演进方向： 从近期历史PR看，sglang仓库持续投入CI基础设施改进，包括测试分区调整、权限管理、工作流优化等。本PR是这一方向的延续，体现了团队对CI效率和资源利用率的关注。这种"快速失败"模式未来可能扩展到其他类型的检查（如单元测试、构建检查），形成更全面的CI健康检查体系。