AskaEth
e3ee20bdcd
清单挂 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
30 lines
822 B
JSON
30 lines
822 B
JSON
{
|
|
"channel": "stable",
|
|
"releases": [
|
|
{
|
|
"version": "9.9.9",
|
|
"channel": "stable",
|
|
"released_at": "2026-01-02T03:04:05Z",
|
|
"notes": "golden 样例（自验用，不是真实发布）",
|
|
"force": false,
|
|
"min_supported": "9.0.0",
|
|
"artifacts": [
|
|
{
|
|
"target": "win-x64",
|
|
"format": "portable-exe",
|
|
"url": "unlucky-launcher_9.9.9_windows_x64.exe",
|
|
"size": 12,
|
|
"sha256": "8ac2dbaad20a7b318a75485359b0302d6d2550093b69296cea39db18d4836ef0"
|
|
},
|
|
{
|
|
"target": "linux-x64",
|
|
"format": "portable-zip",
|
|
"url": "unlucky-launcher_9.9.9_linux_x64.tar.gz",
|
|
"size": 12,
|
|
"sha256": "dcd549d0571bb74eaee60af5c0bc702714fb0de052094336ab10e1e0c7faea0e"
|
|
}
|
|
]
|
|
}
|
|
]
|
|
}
|