radixark/miles · 标签视图

单文件 CI 改从 PR 快照解析标签白名单，解除 /rerun-test 阻塞

值得精读，尤其是需要在 CI 中处理不可信输入的同学。重点看两处设计决策：一是 `_read_snapshot_labels()` 用 AST 字面量解析 + symlink 拒收 + 单次定义校验来“读快照而不 import”，这是 fork PR 场景下读取配置的通用范式；二是 `ci_register.py` 用默认参数注入白名单，把行为变更收敛在 file-run 一条路径上，最小化回归面。阅读时可一并追问三点：(a) 是否补 `tests/ci/test/test_file_run.py` 覆盖 symlink/重复定义/非字面量 dict 的错误分支；(b) cwd 契约是否改为显式传入 `labels_path` 更稳妥；(c) 是否需要在文档或注释里固化 `KNOWN_LABELS` 的写法约定。总体属于低风险、高收益的小修补，可放心合并。

镜像补 FlashMLA/cudnn-frontend，DSv4 e2e 切到 cuDNN DSA 后端

建议精读，但重点不在测试文件的一行改动，而在 docker/Dockerfile 中新增的安装块：`--no-deps` 与 `ENABLE_CUDA_13` 门控体现了「镜像依赖决定 CI 能力」的现实约束，是理解本仓库 GPU CI 体系的一个好样本。阅读时重点关注三点：一是 flash_mla wheel 的来源与 torch 版本绑定关系（升级 torch 时需要同步重出 wheel）；二是 5 个 `register_ci_gate` 指标在切换内核后端后是否需要重新标定基线；三是建议后续给 flash_mla 安装补上与其他 wheel 一致的 `ls | grep -q .` 存在性守卫，避免 wheel 缺失时镜像构建直接硬失败。对于只关心业务逻辑的读者，本 PR 可以略过。

nightly 失败 job 自动重跑一次，卡片区分 flaky 与真实失败

值得精读。这个 PR 是 CI 通知链路上的一次小而有代表性的可靠性改进：自动重跑 + flaky 区分的状态机设计（attempt 1 重跑、attempt 2 报告、拒跑兜底、防循环守卫）清晰且可测试。特别值得关注两点：一是作者对未验证路径的诚实标注与 fallback 设计（先合入、后观察、再切换 token 来源），二是 identity boundaries 测试随权限提升同步收紧，保证 actions: write 是唯一新增写权限。建议后续跟踪第一个失败的 nightly，确认 workflow_run 事件确实触发，否则需要切换到 App token。

CPU-only PR 跳过 CUDA/ROCm 镜像准备

值得精读。该 PR 展示了 CI 门控设计中「需求推导」与「复用现有 gate」的平衡，尤其是 diff 缺失时保留 runnable 语义的修复，以及提交历史中「先扩展输出、后回退为复用条件」的演进过程，对理解 milos CI 策略的 stage 选择模型很有帮助。关注 `tests/ci/ci_policy.py` 的 `_write_github_outputs` 与 `tests/ci/stage_selection.py` 的 `select_skipped_gpu_stages` 两处核心逻辑即可。

CUDA 镜像升级 torch_memory_saver，修复暂停态释放崩溃

代码本身只有一行 pin 变更，不值得逐行精读；真正值得读的是评论区与 #3243 的验证链条——它解释了为什么「fork PR 的 GPU 红灯不能当证据」，以及如何用仓内分支承载镜像验证，对任何改 Dockerfile/依赖 pin 的人都直接可复用。关注三个设计决策：选上游修复的 merge commit（最小 bump）而不是跟最新版本；CUDA/ROCm 双 pin 的对称性维护；以及遗留的 segfault 与 backward OOM 必须另开 issue，不能随本 PR 一起关掉。

修复 CI 证据包丢失败块，按失败数分配预算

值得精读。该 PR 展示了日志证据提取管线中的一个典型容量陷阱：下载窗口足够大但逐级预算不匹配导致信息在加工环节丢失。作者用真实数据定位根因，并采用“按失败实体分配预算 + 套件挑选优先”的对策，设计思路可迁移到其他日志抽取、摘要生成等场景。同时 PR 中“已知缺口明确不处理”的取舍也值得学习：避免在取证层无限扩容，把真正的根因修复留给正确的归属层。

Lark CI 卡片按相同失败分析合并 job 行，消除重复刷屏

值得快速精读：源码改动不到 30 行，但“分组键 + 非空护栏 + 保留每 job 链接”是一套通用的告警去重取舍，可直接迁移到其他通知渠道。阅读时建议重点确认三点：分组键选择（整段分析元组是否过严/过松）、空分析必须独立成行的护栏、以及截断（`jobs[:limit]`）在分组前后顺序上的语义。后续可考虑补一个“多个 job 逐条 `UNAVAILABLE_REASON`”的用例，或在分组键中显式过滤哨兵值，以对齐 PR 描述中的承诺。

修复 CI 门控：CPU 失败不再跳过 nightly 的全部 GPU stage

值得精读，但重点不是 22 行代码量，而是两个可复用的工程经验：一是 GitHub Actions 中「无 `if` 的 job 按整个依赖闭包判定 success()」这一反直觉语义导致的跨阶段级联跳过，任何多阶段流水线都可能踩到；二是把这类隐性约束固化成不变量测试的做法。建议进一步关注：把断言从硬编码两个 job 扩展为对 GPU stage 依赖链的遍历式检查；把 `if:`/`always()` 子串匹配升级为按行首正则或 YAML 解析，消除注释误命中；顺带排查 `resolve-ci-policy`、`docker-build` 等同类前置 job 是否都带显式 `always()` 保护。