执行摘要

• 一句话：CI 控制平面作业迁移至 vllm-runners 自托管组
• 推荐动作：值得 CI/基础设施维护者快速阅读，主要收益是理解「GitHub 托管并发上限如何阻塞自托管 autoscaler」这一调度链路问题及其解法。不建议精读源码（无代码逻辑变更）；可以关注其安全论证模式——在把 PR 触发作业放到自托管 runner 时，如何通过「不 checkout PR 代码 + pinned action + 默认分支」来控制风险。

功能与动机

PR body 明确指出两个痛点：一是组织达到 GitHub 托管并发 20/20 上限，“waiting on the GitHub-hosted pre-run-check prevents the dependent self-hosted job from being created, so no workflow_job event reaches the AWS runner autoscaler”，即一个轻量级门禁作业的排队会阻断整个自托管流水线的调度；二是 PR 评论 CI broker 在 ubuntu-latest 上排队 15 分 50 秒后才执行了 15 秒（run 30981284643）。把这两个控制平面作业路由到 vllm-runners 自托管组可以消除对饱和托管池的依赖。

实现拆解

1. 诊断并发瓶颈：通过 PR body 中的排队时间数据和 20/20 并发上限说明，确认瓶颈不在自托管 runner 本身，而在于 pre-run-check 和 run-ci-command 这两个前置作业依赖 GitHub 托管池，拖慢了下游自托管作业的创建与 AWS autoscaler 的触发。
2. 修改 .github/workflows/pre-commit.yml：将 pre-run-check 作业的 runs-on 从 ubuntu-latest 改为 [self-hosted, linux, x64, vllm-runners]，与仓库既有自托管选择器保持一致；该作业仅运行 pinned 版本的 actions/github-script 读取 PR 元数据，不 checkout 也不执行 PR 代码。
3. 修改 .github/workflows/run-ci-command.yml：将 run-ci-command 作业的 runs-on 同样改为 [self-hosted, linux, x64, vllm-runners]，并保留其显式 checkout 默认分支与授权检查逻辑后再向 Buildkite 派发。
4. 安全论证与验证：PR body 明确了两个作业均不触碰 PR head 代码，且 runner 为 ephemeral 实例；变更通过 actionlint 校验，无测试、配置或部署配套改动（纯 workflow 调度调整）。
5. 合并先前的独立 PR #51128：原先单独的 comment broker 变更被并入本 PR，避免重复工作。

关键文件：

• .github/workflows/pre-commit.yml（模块 CI 工作流；类别 infra；类型 infrastructure；符号 pre-run-check）: 该文件是 pre-commit 门禁流水线的定义，pre-run-check 作业的 runner 迁移是本 PR 的核心变更之一，直接影响下游自托管 pre-commit 作业能否及时创建。
• .github/workflows/run-ci-command.yml（模块 CI 工作流；类别 infra；类型 infrastructure；符号 run-ci-command）: 该文件是 PR 评论触发 Buildkite CI 的 broker 作业，原先在 ubuntu-latest 上排队 15 分 50 秒，迁移到 vllm-runners 后消除托管池排队瓶颈。

关键符号：未识别

关键源码片段

.github/workflows/pre-commit.yml

该文件是 pre-commit 门禁流水线的定义，pre-run-check 作业的 runner 迁移是本 PR 的核心变更之一，直接影响下游自托管 pre-commit 作业能否及时创建。

# 本片段展示 pre-commit.yml 中 pre-run-check 作业的 runner 选择变更
#（总改动仅此 1 行，其余步骤逻辑保持不变）
permissions:
  contents: read
jobs:
  pre-run-check:
    # 仅 pull_request 事件触发；不 checkout 也不执行 PR 代码，
    # 因此放到自托管 runner 上运行不会引入不可信代码执行面
    if: github.event_name == 'pull_request'
    # 关键变更：从 GitHub 托管的 ubuntu-latest 迁移到自托管 vllm-runners 组
    # 目的：绕开 GitHub 托管并发 20/20 上限，让下游 pre-commit 作业
    # 尽快获得 workflow_job 事件并触发 AWS runner autoscaler 扩容
    runs-on: [self-hosted, linux, x64, vllm-runners]
    steps:
      - name: Check PR label and author merge count
        # 只读取 PR 元数据（label、作者合并次数），对 PR 代码零接触
        uses: actions/github-script@3a2844b7e9c422d3c10d287c895573f7108da1b3 # v9.0.0

评论区精华

该 PR 没有实质性的 review 讨论。唯一的评论来自 claude[bot]，是仓库配置的自动引导消息，提示维护者可用 @claude review 命令触发人工代码审查，本身不构成技术讨论。PR body 由提交者自述了安全边界（pre-run-check 不 checkout PR 代码、run-ci-command 使用默认分支并保留授权检查）和重复工作排查（搜索了多个关键词确认无其他 PR 处理同一变更），但这些是作者声明而非评审者交锋。

• 暂无高价值评论线程

风险与影响

• 风险：
  1. 自托管 runner 执行 PR 触发作业的安全边界：pre-run-check 由 pull_request 事件触发，fork 的 PR 也能触发该作业在自托管 runner 上运行。虽然 PR body 声明该作业只运行 pinned 的 actions/github-script 且不 checkout PR 代码，但自托管 runner 承载外部 PR 触发的作业本身风险高于 GitHub 托管，任何对该 workflow 的后续改动都需要维持这一安全前提。
  2. 自托管 runner 组负载增加：vllm-runners 组同时承载 pre-commit、Buildkite 派发等作业，两个控制平面作业迁移过去后，如果 autoscaler 扩容不及时，可能出现自托管组内部排队，把瓶颈从「托管池饱和」转移到「自托管池饱和」。
  3. 无自动化验证：runner 选择变更没有对应的 CI 测试或合成检查，只能依赖人工 review 和线上运行观察；如果标签组合在部分自托管机器上不匹配，作业会持续 pending 而不会立刻报错。
     - 影响：影响范围限于 CI 基础设施：所有通过 PR 评论触发 vLLM CI 的开发者与 maintainer 会感知到触发延迟降低（从 15 分钟级排队降为秒级调度）；pre-commit 门禁的排队阻塞被解除后，AWS autoscaler 能更及时收到 workflow_job 事件并扩容自托管 runner。对模型推理、vLLM 运行时等生产代码无任何影响。影响程度为中等：是 CI 可靠性的关键改进，但改动面极小（每文件仅 1 行）。
     - 风险标记：自托管 runner 处理 PR 触发作业, 并发瓶颈转移至自托管组, 变更无自动化测试覆盖

关联脉络

• PR #51128 PR-comment CI broker 独立变更（已被本 PR 并入）: PR body 明确说明“The former standalone comment-broker change in #51128 has been folded into this PR”，即原先独立的评论 broker 变更合并进了本 PR，避免重复 PR。
• PR #51087 [CI] Add run-all comment commands: 该 PR 修改了同一个 .github/workflows/run-ci-command.yml 文件并新增 /ci run all、/ci run nightly 等评论命令，本 PR 将 broker 作业迁移到自托管 runner，属于同一 CI 命令链路的演进。