执行摘要

• 一句话：PR 携带 bypass-fastfail 标签则跳过阶段等待
• 推荐动作：本 PR 是 CI 基础设施的一次小改进，值得关注其设计思路，但存在 review 中提出的两个潜在问题，后续可考虑改进。

功能与动机

为了配合之前新增的 bypass-fastfail 标签（PR #24577 引入），当标签存在时，CI 应跳过 stage 间等待，使所有 stage 像定时运行一样并行执行，加快 CI 反馈速度。

实现拆解

1. 在 .github/actions/wait-for-jobs/action.yml 的 JavaScript 运行逻辑中，在开始轮询之前，先获取当前 PR 的标签列表。如果标签中包含 bypass-fastfail，则立即通过 core.setOutput('result', 'success') 返回成功，不再执行后续等待逻辑。
2. 获取标签时，优先使用 context.payload.pull_request.labels（快捷但仅反映触发时的状态），若该 payload 中没有 PR 上下文，则通过 GitHub API 根据 commit SHA 查询关联的 Pull Requests，取第一个 PR 的标签。
3. 在 .github/workflows/pr-test.yml 中添加注释，说明 bypass-fastfail 标签的作用，并提示标签处理逻辑在 action 内部实现。

关键文件：

• .github/actions/wait-for-jobs/action.yml（模块 CI 动作；类别 infra；类型 infrastructure）: 实现了根据 PR 标签跳过等待的核心逻辑，是变更的主要载体。
• .github/workflows/pr-test.yml（模块 CI 工作流；类别 infra；类型 infrastructure）: 增加了注释说明 bypass-fastfail 标签的行为，便于理解 CI 流程。

关键符号：未识别

关键源码片段

.github/actions/wait-for-jobs/action.yml

实现了根据 PR 标签跳过等待的核心逻辑，是变更的主要载体。

# .github/actions/wait-for-jobs/action.yml
# 在轮询之前，新增 bypass-fastfail 标签检查逻辑
    steps:
      - name: Wait for Jobs
        uses: actions/github-script@v7
        with:
          script: |
            const { context, core, github } = require('@actions/github');
            // 获取 PR 标签列表
            let labels = [];
            if (context.payload.pull_request?.labels) {
              labels = context.payload.pull_request.labels.map(l => l.name);
            } else {
              // 如果 payload 中没有 PR 信息，通过 commit 查询关联 PR
              const ref = context.payload.pull_request?.head?.sha || context.sha;
              try {
                const { data: prs } = await github.rest.repos.listPullRequestsAssociatedWithCommit({
                  owner: context.repo.owner,
                  repo: context.repo.repo,
                  commit_sha: ref,
                });
                if (prs.length > 0) {
                  labels = prs[0].labels.map(l => l.name);  // 注意：只取第一个 PR 的标签
                }
              } catch (e) {
                console.log(`Could not fetch PR labels for ${ref}: ${e.message}`);
              }
            }
            if (labels.includes('bypass-fastfail')) {
              console.log(`Skipping ${stageName} wait (bypass-fastfail label present)`);
              core.setOutput('result', 'success');
              return;
            }
            // ... 原轮询逻辑继续

评论区精华

review 中 gemini-code-assist[bot] 提出了两个问题：

1. 使用 context.payload.pull_request.labels 依赖工作流触发时的标签快照，若用户在运行后添加标签则无法检测到，建议在轮询循环中动态获取最新标签。
2. 一个 commit 可能关联多个 PR，仅检查第一个 PR 的标签可能遗漏，建议聚合所有关联 PR 的标签。
   目前这两个问题均未在 PR 中解决，PR 已合并。

• 动态获取标签以避免快照问题 (correctness): 未采纳，PR 已合并。
• 聚合所有关联 PR 的标签 (correctness): 未采纳，PR 已合并。

风险与影响

• 风险：
  1. 标签获取可能滞后：若用户在 workflow 启动后添加 bypass-fastfail 标签，当前实现无法检测到，可能导致不必要的等待。
  2. 标签检查仅针对第一个关联 PR，若 commit 关联多个 PR，可能漏掉其他 PR 上的标签。
  3. 跳过等待可能导致 stage 在依赖条件未满足时就开始执行，但该行为与定时运行一致，风险较低。
     - 影响：影响范围限于携带 bypass-fastfail 标签的 PR 的 CI 流程。对于这些 PR，CI 从串行 stage 执行变为并行执行，总体完成时间将显著缩短。对不携带该标签的 PR 无影响。
     - 风险标记：标签快照可能过时, 仅检查首个关联 PR

关联脉络

• PR #24577 Add bypass-fastfail label for check-stage-health: 引入 bypass-fastfail 标签的原始 PR，当前 PR 为其提供了实际跳过等待逻辑。