 worker-updatee2e
|
68a1f90828
|
fix(m169): 复审 r2 —— 守门归属改成「列表项结构判定 + 默认拒绝」，堵掉无名步骤/无名 job/flow 步骤的继承放行
r2 复审（reviewer-updatee2e-r2，p2-4items；被抓出一个真洞，mission 翻回 active）逐条落地。
P2-1（本轮核心，真洞）allowlist 的归属原来按「最近一行 `- name:`」切块，于是任何不写成
`- name: <x>` 的步骤都继承上一块的名字；被放行的 `update-e2e` 恰好是 ci.yml 里最后一个
`- name:`，所以追加到文件末尾的一切都落在它的块里。复审三条真实注入（无名 `- run:`、无名步骤的
整个 job、flow 风格步骤）当时全绿。现在：
- `split_items()` 按 YAML **列表项**切块（每个 `- ` 起一项；比当前项深的行归当前项；同级或更浅的
非列表行**结束**当前项）。项名 = 该项内**同级**的 `name:` 键（键序无关；`run: |` 块里的
`name: dummy` 不算；`run: echo "name: x"` 也不算）。
- **默认拒绝**：落不到列表项上的行（`jobs:` 之前的孤儿行、job 级 `run:` 这类项外键）带 feature 即红；
没有 `name:` 的项带 feature 即红。不再有「继承上一块」这回事。
- 三条复审注入 + 本轮新增三条（`jobs:` 之前的孤儿行、`run: |` 里夹带并伪造 name、shell 变量拼接）
都进了自测向量；在**真仓库文件**上重跑也是全红。
P2-2（同族误杀）：
- 键序无关：允许的那一步把 `run:` 写在 `name:` 之前仍绿（旧实现会报到上一块的名字上）。
- `cargo hack check --all-targets` 不再被误判成 `--all`（正则收紧到 `--all(?![-\w])`）。
- Cargo 的 `update-test-source = [ … ]` **跨行声明**不再被误判成「写进了别的 feature 列表」
（`scan_manifest` 增加 `in_declaration` 状态）。
P2-3 `Fixture::run` 的第二条断言比错对象：原来比夹具字段 `self.dest`，手写
`fx.run(&["apply","--dest","<测试二进制>","--json"])` 两条都过。现在从 `args` 里解析真实 `--dest`
值（含 `--dest=` 形式）再 canonicalize 比较；夹具字段那份作为额外一道保留。
P2-4 `release-guard.yml` 的步骤级注释还停在 r1 的扫描面：改成「含复合 action / packaging 递归 /
Makefile 等 + 归属按列表项判 + 唯一允许 ci.yml 的 update-e2e 一步」。
自测数据搬到 `packaging/tests/guard_vectors.json`（基线 8 个文件 + 26 条向量：21 红 / 6 绿），
脚本本身从 379 行降到 373 行（守门仍 ≤400）；README §14 补上归属规则与「抓不住」清单。
验证（本机，全部 exit 0）：
- 守门正式扫描绿；`--self-test` 21 条注入全红 + 6 条基线/放行绿；向量文件缺失时 exit 1（不静默）。
- **真仓注入**（在真 ci.yml / release-build.yml / cli/Cargo.toml 上改完即还原）：复审三条（无名步骤 /
无名 job / flow 步骤）全红；本轮新增三条（孤儿行 / `run: |` 夹带 / shell 拼接）全红；
三条合法写法（键序、`--all-targets`、跨行声明）全绿；还原后基线绿。
- E2E：debug 6 绿、release 6 绿（`running 3 tests` ×2，0.26s / 0.23s，非 0 measured）。
- `cargo clippy -p unlucky-cli --all-targets --features update-test-source -- -D warnings` 干净；
`cargo fmt --all -- --check` 干净；全仓 400 行扫描无超限（守门 373 / 向量 194 / ci.yml 317）。
约束遵守：未 push；`PUBLISH_SLOTS` 只列 `windows-x64`（未动）；release 侧仍无该 feature；跨卷 bug 未碰。
⚠ 仍未验：CI 里 E2E 真跑起来本机验不了（只证明 workflow 写对 + 守门放行，首跑要等推送后看 Actions）。
|
2026-11-08 11:12:11 +08:00 |
|
 AskaEth
|
e3ee20bdcd
|
feat(packaging): M151 发布流水线生成更新清单 manifest.json（D50）
清单挂 GitHub Release 资产，固定文件名 manifest.json（D50）。字段形状的权威是 M146 的
crates/core/src/update/manifest.rs（ReleaseManifest，deny_unknown_fields + 逐字段校验），
生成器只负责把那套形状填对，不另立 schema。
同源，不双写：packaging/make_manifest.py 的每个 sha256 直接读 Release 自己的
SHA256SUMS.txt，size 取自同一批文件的 stat()；产物名里的版本段必须等于 --version，
tag 与 Cargo.toml 漂了就没有产物可对，当场失败。CI 在「裁剪发布白名单后重算
SHA256SUMS」之后调它，所以清单描述的是真正要发的资产，不是构建出来的全部。
make_artifacts.py 只加 --manifest 开关，用子进程调同一份脚本（本地跑也产出
manifest.json），本文件继续是产物命名的唯一真相源。
只放启动器产物：DTO 的 Artifact 没有角色字段，Release::artifact_for() 取第一个
target 命中的产物，把 ull 并列写进去会让「覆盖哪个文件」取决于数组顺序；ull 照旧进
SHA256SUMS.txt 与 Release。
url 两种形态：默认裸文件名（DirSource 口径，本地/内网用）；CI 传 --asset-base-url
拼绝对地址并钉 tag（不是 latest），清单里每条都指向与它自报版本相符的字节。
自验：--self-test 用 packaging/tests/manifest.golden.json 逐字节对拍（覆盖裸 exe 与
tar.gz 两种形态，并钉住「ull 不进清单」），再跑 14 条负例证明严格解析不是摆设；
发布步会先跑它再产文件。真 DTO 对拍已在本机用 M146 的 ReleaseManifest 实测：
golden 解析通过（2 个产物、min_supported、force 均正确落位），14 条篡改全部被拒。
未决（报告带利弊，未自行改发布默认值）：releases/latest/download/* 只指向非 prerelease
的最新 Release，而发布默认 prerelease=true。
Refs: D50, M146
|
2026-11-06 22:15:58 +08:00 |
|