Unlucky-Launcher

0 Fork 0

Files

T

AskaEth a6060e7649 fix(cache): 发布侧 key 只取 inputs.os 且 tag run 只读不写（M270 r1 复审 P2）

r1 复审（p2-1items）指出：tag 触发的 run 只能读 main 或同名 tag 的缓存，而 main 上
没有任何 job 跑 ubuntu-22.04 / windows-11-arm 这些标签 ⇒ 发布侧四个槽位每次发布都是冷编，
写出的 target 缓存永远拿不回来，还会占 10 GB 配额把 main 的热缓存 LRU 挤掉。r0 的
「key = inputs.os + inputs.slot」既没解决死缓存，还把 Windows 借 main 热缓存的路掐了。

- 发布侧 key 改成 `${{ inputs.os }}`：linux-x64(22.04) 与 main 的 ubuntu-latest 仍然不同
  key（M269 那条必须断），而 windows-x64(windows-latest) 与 main 的 ci/build 重新同 key
  —— 同镜像，借它的热缓存安全（M270 前 Windows 一直走这条且产物是绿的）。
- 发布侧加 `save-if: ${{ github.ref_type != 'tag' }}`：tag run 一律不写（写出来是死缓存），
  只有 main 上的 dispatch 预热会写 —— 那次 run 的作用域是 main，之后的 tag run 才读得到。
  刻意不用 `cache-targets: false`：那会把 Windows 借热缓存的路一起掐掉。
- ci.yml 侧只修 Nit：`Linux-X64` → `Linux-x64`（node 的 os.arch() 是小写）。
- docs 照实重写：tag 缓存作用域、发布侧每次冷编的必然性、预热怎么做、只读不写防什么、
  「同一镜像标签但底层悄悄升级」这档剩余风险与手动 bump 办法；并补回 M164 MSYS 报错的
  原文（可搜索的指路）。新的 key 演算：改前主 key 相同 2 对（跨镜像 1 对）/ 跨镜像前缀
  命中 2 组；r1 = 1 对（全是同镜像 windows）/ 0 组。

2026-11-12 10:31:23 +08:00

artifacts-and-version.md

ci(release): 发布工作流加显式 run-name，Actions 列表不再显示提交信息（M268）

2026-11-12 09:29:01 +08:00

build-and-ci.md

fix(cache): 发布侧 key 只取 inputs.os 且 tag run 只读不写（M270 r1 复审 P2）

2026-11-12 10:31:23 +08:00

compliance-support-boundaries.md

ci(m184): linux-x64 进发布名单，两档 Linux 转 mode=ci，arm64 只构建不发布

2026-11-08 21:35:26 +08:00

gpu-evidence.md

fix(ci)+test(packaging): 关掉「门禁关死而自检全绿」三条路：outputs 绑定、判据步真跑、自检步指向