执行摘要

• 一句话：调整发布流水线顺序，构建完成后统一发布
• 推荐动作：该 PR 改动安全且必要，建议合并。后续可单独处理 gemini-code-assist 提出的 nightlty 条件过滤建议，进一步提升 nightly 自动化程度。

功能与动机

PR body 明确指出：所有构建步骤（包括 ROCm）必须完成后再进行发布，以防止发布操作与正在进行的构建产生竞态。

实现拆解

1. 从原流水线中间删除 Publish release images to DockerHub 块（block + label）和 Publish wheels 组。
2. 在流水线末尾、所有构建和 ROCm 步骤之后重新插入上述发布步骤。
3. 保持所有 depends_on 引用不变（指向原有的 step ID）。
4. 添加注释 Publish to DockerHub and PyPI (at the end so all builds complete first) 明确意图。

关键文件：

• .buildkite/release-pipeline.yaml（模块 CI配置；类别 infra；类型 configuration）: 唯一变更文件，通过调整步骤位置实现发布顺序控制，是发布流水线的核心配置。

关键符号：未识别

评论区精华

• Harry-Chen 建议触发 dry-run 验证顺序有效性；khluu 创建了 Buildkite job 并确认步骤已正确移到最后。

• gemini-code-assist[bot] 指出 Publish wheels 组缺少 if: build.env("NIGHTLY") != "1"，可能导致 nightly 构建中出现手动确认块，建议补充。该建议未在本次 PR 中处理。

• Dry-run 验证发布流水线顺序 (testing): 验证通过，顺序正确。

• 为 Publish wheels 组添加 nightly 条件 (design): 未在本次 PR 中处理，建议后续单独修复。

风险与影响

• 风险：
  • 依赖解析风险：虽然 depends_on 引用保持不变，但 YAML 流水线中步骤的物理顺序改变仍可能影响 Buildkite 的依赖图解析，需通过 dry-run 验证。
  • nightly 流程干扰：Publish wheels 组未添加 nightlty 条件过滤，自动化 nightly 构建可能被手动确认块阻塞。
  • 无脚本逻辑修改：发布脚本本身无变更，因此发布逻辑本身风险低。
  • 影响：仅影响 release-pipeline.yaml 的执行顺序，对开发者日常开发、用户推理服务无直接影响。改进发布流水线的可靠性和一致性，避免构建未完成时错误发布。
  • 风险标记：缺少 nightly 条件过滤, YAML 步骤顺序影响依赖图, 发布流程变动需 dry-run 验证

关联脉络

• 暂无明显关联 PR