Skip to content

Commit 299e691

Browse files
KaisennHuKaisennHu
committed
docs(knowledge): add vLLM-Router release standard
- repos/vllm-router: repo entry, CI entry, release gates (tag/pyproject version check, dual-arch wheel + smoke, PyPI and Docker publish order, policy gates) - register in repos/_index.md and add the vllm-router ownership tag to SCHEMA.md
1 parent ecfb84d commit 299e691

5 files changed

Lines changed: 239 additions & 3 deletions

File tree

‎doc/knowledge/SCHEMA.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -81,7 +81,7 @@ contradictions: [相对路径] # 可选：与本页冲突的页面
8181

8282
新标签必须先加入此表再使用（防止标签蔓延）：
8383

84-
- 归属：`general`、`vllm-omni`、`afd-plugin`、`vllm-gr`、`jiuwenswarm`
84+
- 归属：`general`、`vllm-omni`、`afd-plugin`、`vllm-gr`、`jiuwenswarm`、`vllm-router`
8585
- 工作主题：`review`、`ci`、`docs`、`git`、`debug`、`bug`、`benchmark`、`environment`、
8686
`remote`、`agents`、`planning`、`dev`、`rebase`
8787
- 代码/模型轴：`components`、`models`、`diffusion`、`model-executor`、`serving`、

‎knowledge/repos/_index.md‎

Lines changed: 3 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,9 +1,9 @@
11
---
22
title: "仓库经验入口"
33
created: 2026-07-10
4-
updated: 2026-09-30
4+
updated: 2026-11-06
55
type: index
6-
tags: [vllm-omni, afd-plugin, vllm-gr]
6+
tags: [vllm-omni, afd-plugin, vllm-gr, vllm-router]
77
sources: []
88
---
99

@@ -28,3 +28,4 @@ sources: []
2828
| Jianghan roleplay data pipeline | 私有项目 | [jianghan-roleplay-data-pipeline](jianghan-roleplay-data-pipeline/_index.md) |
2929
| vLLM-GR | `JiusiServe/vllm-gr` | [vllm-gr](vllm-gr/_index.md) |
3030
| jiuwenswarm | `openJiuwen-ai/jiuwenswarm` | [jiuwenswarm](jiuwenswarm/_index.md) |
31+
| vLLM-Router | `vllm-project/router` | [vllm-router](vllm-router/_index.md) |

‎knowledge/repos/vllm-router/_index.md‎

Lines changed: 37 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,37 @@
1+
---
2+
title: "vLLM-Router 入口"
3+
created: 2026-11-06
4+
updated: 2026-11-09
5+
type: index
6+
tags: [vllm-router]
7+
sources: [pyproject.toml, .buildkite/README.md, "vllm-project/router@ddf78218cffdb6361579d3babd69a90ba6d63aaa"]
8+
---
9+
10+
# vLLM-Router
11+
12+
上游：`vllm-project/router`。PyPI 包 `vllm-router`，Python 模块 `vllm_router`，console
13+
script 与 Rust 二进制都叫 `vllm-router`。别名：`vllm-router`、`vllm_router`、`router`（本地
14+
目录名）。默认分支 `main`；本切片的发版事实按 `main@ddf78218` 与 tag `v0.1.17` 核对。
15+
16+
## 什么时候查这里
17+
18+
- 判断本仓库怎么发版：tag 形态、版本号要同步哪几份文件、PyPI/镜像产物哪些是硬门禁。
19+
- 区分 L1 ready / L2 merge / L3 nightly 与 `release` 四条 Buildkite 通道的适用范围。
20+
21+
## 不放什么
22+
23+
- 跨仓库通用的发版、CI 和 DI 口径 → [通用 CI](../../general/ci/_index.md)、[DI 计算说明](../../general/bug/guides/di-calculation.md)。
24+
- 机器地址、queue 凭据、本地 checkout 路径 → Git 忽略的 `local/`。
25+
26+
## 目录内容
27+
28+
| 遇到什么 | 查看哪里 | 说明 |
29+
|---|---|---|
30+
| 发版门禁、tag 与版本号同步、PyPI/Docker/GitHub Release 产物核对和常见失败 | [发布规范](ci/release-gates.md) | `release-pipeline.yml` 真实执行的门禁 + 发布前质量门槛 |
31+
| L1/L2/L3 通道、pytest marker、GPU preset、nightly 与 release 的分工 | [CI 入口](ci/_index.md) | 只写本仓库相对通用 CI 的差异 |
32+
33+
## 当前边界
34+
35+
本切片只覆盖 CI 与发布。`components/`、`models/` 和代码 owner 路由（`_routes.yaml`）尚未建立，
36+
也没有 adapter；审查本仓库代码时不能把发布页当代码 owner，必须按 live 源码和 PR changed
37+
files 自行定位。

‎knowledge/repos/vllm-router/ci/_index.md‎

Lines changed: 57 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,57 @@
1+
---
2+
title: "vLLM-Router CI"
3+
created: 2026-11-06
4+
updated: 2026-11-09
5+
type: index
6+
tags: [vllm-router, ci]
7+
sources: [.buildkite/README.md, .buildkite/pipeline.yml, .buildkite/test-ready.yml, .buildkite/test-merge.yml, .buildkite/test-nightly.yml, .buildkite/release-pipeline.yml, .buildkite/ci_mirror_hardwares.yml, .buildkite/scripts/build-ci-image.sh, pytest.ini, tests/python/helpers/mark.py, "vllm-project/router@ddf78218cffdb6361579d3babd69a90ba6d63aaa"]
8+
---
9+
10+
# vLLM-Router CI
11+
12+
## 什么时候查这里
13+
14+
- 判断某类改动该进 L1 ready、L2 merge 还是 L3 nightly，或核对某个 job 的实际触发条件。
15+
- 发版前确认默认分支上哪条通道的结果才算证据 → 见下面目录里的发布规范。
16+
17+
## 不放什么
18+
19+
- 跨仓库通用的测试选择方法 → [通用 CI](../../../general/ci/_index.md)。
20+
- 具体 job 的历史失败复盘；需要时看对应 Buildkite build。
21+
22+
## 上传条件
23+
24+
`pipeline.yml` 先构建 Rust release 二进制、wheel 和 NVIDIA CI 镜像，再按分支和 label 上传三个
25+
测试文件。上传只依赖 `build` 组，彼此不依赖；GPU job 还要等 `image-build`。CI 镜像由
26+
`docker/Dockerfile.ci` 推到共享 ECR，tag 里带 `router-<commit>`，不会顶掉同 commit 的其他项目镜像。
27+
28+
| 通道 | 触发 | 内容 | 证据边界 |
29+
|---|---|---|---|
30+
| L1 ready | 非默认分支带 `ready` label（fork 也跑） | Rust 单测/集成（`--features cpu,ready`）、Python 单测（`-m "ready and cpu"`，`--ignore=tests/python/e2e`，产出 `coverage.xml`）、P/D smoke（4×L4，`SKIP_LM_EVAL`，1 条 sanity）、kv_aware e2e（2×L4）、gRPC P/D smoke（4×L4，`RUN_LM_EVAL=0`） | 只证明该 PR 自身可合并，不能当默认分支健康度 |
31+
| L2 merge | 默认分支 push（`NIGHTLY != 1`）、merge queue（base 为默认分支）、或 `merge-test` label | xGMI smoke（`read_mode=true`、GSM8K `LM_EVAL_LIMIT=20`、基线 0.38 允许 −0.03）、RDMA `SMOKE_ONLY`（两节点） | 默认分支健康度与 ROCm 平台基线 |
32+
| L3 nightly | 默认分支 `NIGHTLY=1`，或 `nightly-test` label | 单测（PR 同时带 `ready` 时整组跳过）、P/D 全量 GSM8K（HTTP 与 gRPC）、gRPC prefix-KV perf（`rust_grpc` + `python_http`，`c16-r32`、`hit99-c4`、`hit99-c64`，2×H100）、L1 encode perf（Qwen3-0.6B，1×L4，`hit0.30`/`hit0.99999` × `c4`/`c16`，L1 on/off）、ROCm xGMI 与 RDMA 的 read true/false 矩阵 | 覆盖最广，但不阻塞 PR，过期结果不能当发版证据 |
33+
| release | `v*` tag 或手动触发 | 只构建 wheel/二进制、smoke、发 PyPI、发镜像 | 不跑 L1–L3，见发布规范 |
34+
35+
几处窄 gate 容易漏：L1 与 L3 的 NVIDIA GPU job 在 `ROCM_ONLY=1` 时跳过；L3 的 xGMI 还接受
36+
UI/API 加 `RUN_ROCM_XGMI=1`，RDMA 只接受 schedule 加 `NIGHTLY=1`、`nightly-test` label，或
37+
UI/API 加 `RUN_ROCM_RDMA=1`。
38+
39+
## 测试分级标记
40+
41+
- 层级与机器用 pytest marker 表达：`ready`、`L4`、`MI300`、`cpu`、`cuda`、`rocm`、`gpu`、
42+
`cards_{1,2,4}`，登记在 `pytest.ini`；`hardware_test(res=..., num_cards=N)` 会派生对应
43+
SKU/平台/卡数 mark（`tests/python/helpers/mark.py`）。
44+
- 新增或改动测试必须带层级和机器标记，`pre-commit` 的 `check-mark`
45+
（`tools/pre_commit/check_test_marks.py`）会拦缺标记的 PR；Rust 侧用 Cargo feature（`cpu`、`ready`）。
46+
- L3 的 Rust 与 Python 单测和 L1 用同一组 `--features cpu,ready` / `-m "ready and cpu"`，单测覆盖
47+
不随层级变大；L3 多出来的是 GPU/ROCm 矩阵、GSM8K 和两个 perf job。
48+
- GPU job 在 `ci_mirror_hardwares.yml` 里按 preset 取机器：`l4_1`（L1 encode perf）、
49+
`l4_2`（kv_aware）、`l4_4`（P/D 与 gRPC）、`h100_2`（prefix-KV perf）、`mi300_2`（xGMI）、
50+
`mi300_rdma`（两节点 RDMA）。job 写 `mirror_hardwares`，由 `scripts/upload_pipeline.py` 展开成
51+
agents 和 plugins。
52+
53+
## 目录内容
54+
55+
| 遇到什么 | 查看哪里 | 说明 |
56+
|---|---|---|
57+
| 发版门禁、tag/版本一致性、PyPI 与 Docker 发布顺序、发布产物核对 | [发布规范](release-gates.md) | 硬门禁与质量门槛分栏，含常见失败模式 |

‎knowledge/repos/vllm-router/ci/release-gates.md‎

Lines changed: 141 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,141 @@
1+
---
2+
title: "vLLM-Router 发布规范"
3+
created: 2026-11-06
4+
updated: 2026-11-09
5+
type: guide
6+
tags: [vllm-router, ci]
7+
sources: [.buildkite/release-pipeline.yml, .buildkite/scripts/build-wheel.sh, .buildkite/scripts/publish-release-images.sh, .buildkite/scripts/cleanup-nightly-router-builds.sh, .buildkite/README.md, docker/Dockerfile.router, pyproject.toml, Cargo.toml, py_src/vllm_router/version.py, docs/benchmarks/router_overhead.md, tests/python/e2e/perf/grpc/README.md, tests/python/e2e/perf/l1_encode/README.md, tests/python/e2e/pd_disagg_vllm/test_lm_eval_accuracy.py, .github/ISSUE_TEMPLATE/200-bug-report.yml, "vllm-project/router@ddf78218cffdb6361579d3babd69a90ba6d63aaa", "https://github.com/vllm-project/router/releases/tag/v0.1.17"]
8+
---
9+
10+
# vLLM-Router 发布规范
11+
12+
发布由 tag 驱动：`.buildkite/release-pipeline.yml`（Buildkite `router-release`）只负责
13+
tag→产物的机械门禁，测试矩阵、质量门槛和 GitHub Release 正文都要维护者举证或手写。
14+
两者必须分开报告，不能把 `release` 流水线通过当成整轮质量验证。
15+
16+
相关入口：[CI 入口](_index.md)、[仓库入口](../_index.md)、[通用 CI](../../../general/ci/_index.md)、
17+
[DI 计算说明](../../../general/bug/guides/di-calculation.md)、[benchmark 合同](../../../general/benchmark/guides/benchmark-contract.md)。
18+
19+
## 版本号与 tag
20+
21+
| 项 | 规定 |
22+
|---|---|
23+
| tag 形态 | `vX.Y.Z`（如 `v0.1.17`）；流水线用 `build.tag =~ /^v.*/` 触发 |
24+
| 版本唯一来源 | `pyproject.toml` 的 `project.version`；`version-check` 只把 tag 去掉 `v` 后与它比较 |
25+
| 必须同步的文件 | `pyproject.toml`、`Cargo.toml`、`Cargo.lock`、`py_src/vllm_router/version.py`；`v0.1.17` 的 bump commit 同时改这四份，tag 指向该 commit |
26+
| 包名与入口 | PyPI 包 `vllm-router`，模块 `vllm_router`，console script 与 Rust 二进制都叫 `vllm-router` |
27+
| 产物范围 | 仅 Linux：`cp38-abi3` 的 manylinux_2_28 x86_64 与 aarch64 wheel，加 sdist；`requires-python = ">=3.8"`，一个 abi3 wheel 覆盖 3.8+，没有 macOS/Windows wheel |
28+
| tag 类型 | 历史上 annotated（`v0.1.16`、`v0.1.16.1`）和轻量（`v0.1.17`）都出现过；类型不影响触发，但 tag 不能指向 bump 之前的 commit |
29+
| 四段版本 | `v0.1.16.1` 打在自己的 `pyproject.toml` 仍是 `0.1.16`，且版本一致性门禁 2026-10-24 才引入；这类版本只能靠手动 Docker 通道发布，不会进 PyPI |
30+
31+
### tag、PyPI、镜像、Release 要分别核对
32+
33+
`v0.1.11`、`v0.1.13`、`v0.1.14` 只有 tag；`v0.1.16.1` 只有 Docker 镜像；GitHub Release 只有
34+
`v0.1.16` 与 `v0.1.17`。2026-11-09 的实测状态：
35+
36+
| 渠道 | 存在的版本 |
37+
|---|---|
38+
| git tag | `v0.1.9` … `v0.1.17`（含 `v0.1.16.1`） |
39+
| PyPI | `0.1.9`、`0.1.10`、`0.1.12`、`0.1.15`、`0.1.16`、`0.1.17` |
40+
| Docker Hub `vllm/vllm-router` | `v0.1.16`、`v0.1.16.1`、`v0.1.17`，加 `latest`、`nightly`（另有 `v0.0.0` 测试 tag） |
41+
| GitHub Release | `v0.1.16`、`v0.1.17` |
42+
43+
结论：tag 列表不能当发布清单用，验收要分别去 PyPI、Docker Hub 和 Releases 页核对。
44+
45+
## 流水线实际执行的门禁（硬）
46+
47+
| # | 门禁 | 证据 job / 脚本 | 失败后果 |
48+
|---|---|---|---|
49+
| 1 | tag 版本 == `pyproject.toml` 版本 | `version-check`（仅 tag 构建） | 后续 build/publish 全部不执行 |
50+
| 2 | 两架构产物构建成功：x86_64 出二进制 + wheel + sdist，aarch64 出 wheel；在 manylinux_2_28 镜像里 `cargo build --release` + `python -m build` + `auditwheel repair`，Rust 用 nightly 工具链 | `build_wheels_x86_64`、`build_wheels_aarch64` | PyPI 发布阻塞 |
51+
| 3 | 二进制 smoke：`vllm-router --version`、`--help` 在 manylinux 容器内可执行 | `smoke-test-binary-x86_64` | PyPI 发布阻塞 |
52+
| 4 | wheel smoke：两个架构各自 `pip install` 后 `import vllm_router` 并打印 `__version__` | `test-python-wheel-x86_64`、`test-python-wheel-aarch64` | PyPI 发布阻塞 |
53+
| 5 | PyPI 上传用 `twine upload dist/*`（`PYPI_TOKEN`），依赖 2+3+4 全部通过，`soft_fail: false`，只在 tag 构建执行 | `publish-pypi` | 无 PyPI 产物 |
54+
| 6 | Docker 正式版：先填 `X.Y.Z`（required），再依次解除 build 与 publish 两个 block；两个架构分别用 `docker/Dockerfile.router` 构建并推 `vX.Y.Z-{x86_64,aarch64}`，最后合并 manifest | `input-release-version`、两个 block、`publish-release-images.sh release` | 只缺镜像，PyPI 不受影响 |
55+
| 7 | nightly 镜像：`NIGHTLY=1` 才构建 `nightly-{x86_64,aarch64}`，发布 `nightly` 与 `nightly-YYYYMMDD-<sha7>`，随后清理旧 tag 只保留最近 14 个 | nightly 组、`publish-release-images.sh nightly`、`cleanup-nightly-router-builds.sh` | 只影响 nightly 通道 |
56+
57+
门禁**不覆盖**的四处，举证时必须自己说明：
58+
59+
- `release-pipeline.yml` 不跑 L1/L2/L3 测试矩阵（`.buildkite/README.md`：wheels and images only），
60+
只有上面 3、4 两条 smoke。
61+
- `vllm_router.__version__` 只被打印，不与 tag 比较；四份版本文件漏改一份，CI 不会报错。
62+
- wheel 用 nightly Rust 工具链构建，测试流水线固定 `rust:1.95.0`；CI 绿测不等于 wheel 里那份
63+
二进制已验证。
64+
- Docker 通道不校验 tag 与 `pyproject.toml`（`version-check` 只对 tag 构建生效），所以可以只发镜像；
65+
`v0.1.16.1` 就是这么来的。
66+
67+
Docker 通道还有两条运维前提：secret `ROUTER_DOCKERHUB_TOKEN` 只在 Docker job 上映射为
68+
`RELEASE_DOCKERHUB_TOKEN`，需要 Buildkite agent 3.106.0 以上支持 step-level secrets；secret 的
69+
访问策略限定在 `router-release` 流水线、main 或批准的版本 ref，以及 CPU/ARM release 队列。
70+
71+
## 发布前质量门槛（政策，需人工举证）
72+
73+
发布前的质量门槛按本仓库现有的通道收敛：NVIDIA 与 ROCm 的平台覆盖、精度回退都包含在 L2/L3
74+
两行里，不另立单项；性能没有统一百分比，按场景口径举证；覆盖率目标在开工会确定。
75+
类型列中 `Gate` 指不分迭代的硬性门槛，`Guide` 指按当期迭代指南解释并举证。
76+
77+
| # | 要求 | 类型 | 说明 |
78+
|---|---|---|---|
79+
| 1 | 目标 commit 的 L2 merge 全绿，最近一轮 L3 nightly 无失败 | Gate | L2 有 xGMI smoke（GSM8K limit 20，基线 0.38 允许 −0.03）与 RDMA `SMOKE_ONLY`；L3 有 P/D 全量 GSM8K（HTTP 与 gRPC）、ROCm xGMI/RDMA 的 read true/false 矩阵、gRPC prefix-KV perf、L1 encode perf。证据给 Buildkite build 链接，L1 只证明 PR 自身，不能替代 |
80+
| 2 | 单元测试覆盖率达到开工会确定的当期目标 | Guide | 覆盖率先在迭代开工会定成具体目标（数值 + 统计范围），发布时用 CI 产出的 `coverage.xml` 对照；CI 不设固定阈值，没定目标按 N/A 记录 |
81+
| 3 | 性能场景无回退，按各场景自己的口径举证 | Guide | 不设统一百分比，见下面“性能与覆盖率怎么举证” |
82+
| 4 | 需求完成率 > 85% | Gate | 按当期需求清单核对，本仓库无自动化 |
83+
| 5 | 剩余 DI < 30 | Gate | 按 [DI 计算说明](../../../general/bug/guides/di-calculation.md) 逐条定级后累加；定级口径见下方说明 |
84+
| 6 | 无未关闭 critical issue，剩余 bug 均有 assignee | Gate | critical 由同一套 issue 分级口径判定；本仓库无自动化 |
85+
86+
### 性能与覆盖率怎么举证
87+
88+
- **性能不用统一阈值。** prefix-KV 用例按 `tests/python/e2e/perf/grpc/README.md` 的验收口径
89+
分场景比较 rust gRPC（G）、rust HTTP（R）、python HTTP（P）的 `ttft_ms.avg` 与 `e2e_ms.avg`：
90+
hit 0% 时 G 在 ttft 和 e2e 上不得回退于 R 与 P；hit 99% 时 G 在 ttft 和 e2e 上不得回退于 R，
91+
e2e 不得回退于 P，且 G 的 ttft 要比 P 好 20% 以上（`ttft_G <= 0.8 * ttft_P`）。CI 的 L3 job
92+
只跑 `rust_grpc` 与 `python_http` 的 `c16-r32`、`hit99-c4`、`hit99-c64`，`rust_http` 需要本地补齐。
93+
L1 encode 用例按 `tests/python/e2e/perf/l1_encode/README.md` 比较 `wave.summary.encode_ms.p50`
94+
与 `encode_reuse.p50` 在 L1 on/off 之间的差异。CPU overhead 用同机 `cargo bench` 的 baseline
95+
对比。pytest 只校验每个 wave 的统计完整，跨后端验收要人工判读 `results/` 里的 `wave.summary`，
96+
不能声称 CI 已经断言 SLO。
97+
- **覆盖率目标来自开工会，不来自 CI。** 先把当期目标写进迭代记录（Python 单测范围是
98+
`-m "ready and cpu"` 的 `coverage.xml`；如果当期还要求 Rust 覆盖，需另行说明工具和范围），
99+
发布时逐项对照；目标缺失时该项只能记 N/A 并注明原因。
100+
- **DI 需要先有分级。** 公式要求每条未关闭 issue 先定 critical / high / medium / low；
101+
本仓库 bug 模板只打 `bug` label，没有 severity 字段，因此发布前要先确认 router 与 agent-infer
102+
的 issue 分级策略并对齐到同一口径（用 label 或发布记录逐条定级）。口径未确认时 DI 记 N/A，
103+
不能拿 issue 数量代替。
104+
105+
## 发布步骤
106+
107+
1. 确认目标 commit 满足上面 1–6，把证据链接记进验收记录。
108+
2. 提一次版本 bump，四份文件同改，走正常 PR 合并；不要只改 `pyproject.toml`。
109+
3. 在 bump commit 上打 `vX.Y.Z` tag 并推送。
110+
4. 盯 `router-release`：`version-check` → 两架构 build → smoke → `publish-pypi`。
111+
5. 需要镜像时手动走 Docker 通道：填 `X.Y.Z`，依次解除 build 与 publish 两个 block，产出
112+
`vllm/vllm-router:vX.Y.Z`、`:latest` 与两个 per-arch tag。
113+
6. 在 GitHub Releases 补发布说明：现有 `v0.1.16`、`v0.1.17` 的结构是 Highlights / Key Improvements /
114+
Note / Artifacts / Full Changelog / New Contributors，Artifacts 段列出 PyPI 三个文件的 SHA-256、
115+
镜像多架构大小和单架构 tag。流水线里没有 `gh release` 或等价步骤，这段必须手写。
116+
7. `NIGHTLY=1` 只发 nightly：`vllm/vllm-router:nightly` 与 `nightly-YYYYMMDD-<sha7>`，不碰 PyPI，
117+
不能当正式版本；nightly 构建只保留最近 14 个。
118+
8. 发布后把 tag、PyPI、Docker Hub、GitHub Release 四处状态并排核对一遍，缺哪一处就写明原因。
119+
120+
## 常见失败模式
121+
122+
- tag 与 `pyproject.toml` 不一致：`version-check` 直接失败，这是唯一能拦住后续所有产物的门禁。
123+
- 只改 `pyproject.toml`：wheel 装得上，但 `vllm_router.__version__` 还是旧值；smoke 只打印不比较。
124+
- 把 README 的 “CI/CD Pipeline” 当流程依据：该段仍写 `cibuildwheel` 和“`pyproject` 版本变化即发布”，
125+
与实际的 tag 驱动、四文件同步不一致；Dockerfile 路径 `/docker/Dockerfile.router` 倒是对的。
126+
流程以 `.buildkite/release-pipeline.yml` 为准。
127+
- 用 tag 列表判断发布状态：`v0.1.11`、`v0.1.13`、`v0.1.14` 没有任何产物，`v0.1.16.1` 只有镜像。
128+
- 用 nightly 的绿测替代发版证据：nightly 覆盖面最广，但它不阻塞 PR、也不校验 tag 与版本文件，
129+
过期一轮的 nightly 结果不能当本次 tag 的门禁证据。
130+
- 只验证 x86_64：PyPI 与镜像都要求两个架构各自构建并 smoke。
131+
- 声明 macOS/Windows wheel：构建只在 manylinux_2_28 上做，一个 abi3 wheel 覆盖多个 Python 版本，
132+
不是跨平台承诺。
133+
134+
## 验收记录
135+
136+
发布说明或 checklist 逐项给出，缺一项按未通过处理：
137+
138+
- 是否通过（Pass / Fail / N/A），硬门禁与政策门禁分开列。
139+
- 证据链接（Buildkite build、`coverage.xml`、各场景性能 `wave.summary`、开工会记录的覆盖率目标、DI 定级记录、issue 列表）。
140+
- 发布产物核对表（tag / PyPI 版本 / Docker tag / GitHub Release 是否都存在）。
141+
- Guide 项写明当期 Guide 版本或链接；Docker 与 GitHub Release 是否发布单独列出。

0 commit comments

Comments
 (0)