执行摘要
该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
主要修改点：
-
描述更新：将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."，明确新增功能。
-
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），表明变更被直接接受或通过其他渠道验证。
测试验证： 从提交历史可以看出作者进行了自我测试：
- 提交
4040b742："test: intentional lint failure for fast-fail testing" - 故意引入lint错误以验证快速失败机制。
- 提交
5cd4cd31："revert test lint failure" - 回滚测试更改，恢复干净状态。
这展示了作者通过实际测试验证功能有效性的务实做法。
风险与影响
技术风险：
- API依赖风险：实现依赖于GitHub API的
checks.listForRef，如果API调用失败、超时或速率受限，可能影响check-stage-health的正常执行。
- 配置敏感性：逻辑假设lint检查的名称为
'lint'且由GitHub Actions运行，如果lint工作流配置变更（如重命名、使用其他CI工具），可能导致查询失败或误判。
- 边缘情况处理：虽然保留了跳过保护逻辑，但新增的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健康检查体系。
参与讨论