现象
Check Addon Version Weekly 最近可见 10 次周任务全部 failure（2026-05-25 至 2026-07-27），不是一次性网络或 runner 波动。
最新自然样本：
- run: https://github.com/apecloud/apecloud-cd/actions/runs/30228425058
- workflow head:
3d312dbe2b2b2aba82c89a32364e819d78b7da6d
- 9 个数据库矩阵中仅
kafka 成功；postgresql/milvus/rabbitmq/mysql/mongodb/qdrant/redis/elasticsearch 共 8 个失败。
- 每个失败都在完成仓库 checkout/Helm 渲染后，由版本对账脚本确定性返回“最新上游版本在 kubeblocks-addons 与 apecloud-addons 均不存在”，不是 GitHub-hosted runner 故障。
本轮代表性缺口：
- PostgreSQL：
18.4, 18.3, 17.10, 17.9, 16.14, 16.13, 15.18, 15.17, 14.23, 14.22
- MySQL：
9.7.1, 9.6.0, 9.5.0, 9.4.0, 9.3.0, 8.4.9, 8.0.46
- MongoDB：
8.3.7, 8.2.12, 8.0.28, 7.0.39
- Qdrant：
v1.18.3, v1.17.1, v1.16.3
- Redis Stack：
7.4.0-v8, 7.2.0-v20, 6.2.6-v20
- Milvus：
v2.6.21
- RabbitMQ：
4.3.4, 4.2.9, 4.1.8
- Elasticsearch：10 个缺口，包括
9.4.4 至 9.0.8、8.19.9 至 8.16.6、7.17.28；只有 8.15.5 命中。
需要 owner 决策
当前 workflow 把“上游所有 latest 版本尚未进入 addon 仓”整体视为 CI failure。连续 10 周全红后，它已失去可操作信噪比。请明确其中一种合同：
- 发布 SLA 门：为每个数据库指定 owner/SLA，版本缺口在 SLA 内 warning，超期才 failure；或
- 支持矩阵门：仅验证声明支持的版本集合，不追逐所有上游 latest；或
- 严格 latest 门：保留现合同，但必须给 8 个矩阵明确补版本 owner 和到期时间。
验收
- 合同和 owner/SLA 在 workflow/文档中显式；
- 加测试覆盖“支持版本缺失”“上游新版本在宽限期”“未知解析失败 fail-closed”；
- fresh weekly/manual run 的 9 个矩阵按新合同终态，不靠 rerun 旧产物或静默
continue-on-error 洗绿。
本单只做巡检建档；未修改 workflow、addon 版本、secret 或发布环境。
现象
Check Addon Version Weekly最近可见 10 次周任务全部 failure（2026-05-25 至 2026-07-27），不是一次性网络或 runner 波动。最新自然样本：
3d312dbe2b2b2aba82c89a32364e819d78b7da6dkafka成功；postgresql/milvus/rabbitmq/mysql/mongodb/qdrant/redis/elasticsearch共 8 个失败。本轮代表性缺口：
18.4,18.3,17.10,17.9,16.14,16.13,15.18,15.17,14.23,14.229.7.1,9.6.0,9.5.0,9.4.0,9.3.0,8.4.9,8.0.468.3.7,8.2.12,8.0.28,7.0.39v1.18.3,v1.17.1,v1.16.37.4.0-v8,7.2.0-v20,6.2.6-v20v2.6.214.3.4,4.2.9,4.1.89.4.4至9.0.8、8.19.9至8.16.6、7.17.28；只有8.15.5命中。需要 owner 决策
当前 workflow 把“上游所有 latest 版本尚未进入 addon 仓”整体视为 CI failure。连续 10 周全红后，它已失去可操作信噪比。请明确其中一种合同：
验收
continue-on-error洗绿。本单只做巡检建档；未修改 workflow、addon 版本、secret 或发布环境。