ci: 暖缓存作业——上一条加的缓存对 PR 其实一个都命不中 - #423
Open
zeweihan wants to merge 1 commit into
Open
Conversation
## 上一条（#421）没做完 加完缓存后实测：桶确实写出来了（mac 745MB / win 849MB），但 ref 是 `refs/tags/v0.19.1` 与 `refs/pull/421/merge`。 **GitHub Actions 的缓存按 ref 隔离**——一次运行只能读到「同一分支」或「默认分支」 产生的缓存。而 desktop-build.yml 的触发只有 tag 与 PR，**从不在 master 上跑**， 于是写出来的桶全挂在 tag / PR 的 ref 上，对后续 PR 一个都读不到。 连 tag 之间也不共享（各是各的 ref）。 也就是说 #421 那 5.6 分钟的收益，实际是 0。我当时只验了「缓存写入成功」， 没验「下一个 PR 能不能读到」——而后者才是它要解决的问题。 ## 这条补上 新增 cache-warm.yml，在 master 上把桶写进默认分支，之后 PR 才真的能命中。 触发条件收得很窄：只在 */requirements.lock 或两个打包脚本变化时跑（缓存内容只由 这些决定）。这些文件很少动，所以平时根本不跑；动一次重建一次，之后 PR 全部受益。 ## 参数不手抄，从 desktop-build.yml 解析 第一版我照着记忆手写了服务列表，**当场就把 pptx 的 --src 抄错了** （是 pptx-service/backend 不是 pptx-service）。而漂掉的后果比想象严重： 暖出来的桶与构建期需要的不是同一个东西，CI 全绿，缓存要么永远命不中、 要么更糟——命中了但内容不对。 改成运行时从 desktop-build.yml 正则解析出 --service / --src / --requirements 再执行。 解析不到 4 个就硬失败，两边结构漂了会当场报错而不是静默跑偏。 本机干跑验过：两个平台都正确解析出 4 个服务、--src 全对。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
#421 没做完，这条补上
加完缓存后实测：桶确实写出来了（mac 745MB / win 849MB），但看
ref：GitHub Actions 的缓存按 ref 隔离——一次运行只能读到「同一分支」或「默认分支」产生的缓存。而
desktop-build.yml的触发只有 tag 与 PR，从不在 master 上跑，于是写出来的桶全挂在 tag / PR 的 ref 上，对后续 PR 一个都读不到。连 tag 之间也不共享（各是各的 ref）。所以 #421 那 5.6 分钟的收益，实际是 0。 我当时只验了「缓存写入成功」，没验「下一个 PR 能不能读到」——而后者才是它要解决的问题。
改动
新增
cache-warm.yml，在 master 上把桶写进默认分支，之后 PR 才真的能命中。触发条件收得很窄：只在
*/requirements.lock或两个打包脚本变化时跑（缓存内容只由这些决定）。这些文件很少动，所以平时根本不跑；动一次重建一次，之后 PR 全部受益。参数不手抄，从 desktop-build.yml 解析
第一版我照着记忆手写了服务列表，当场就把 pptx 的
--src抄错了（是pptx-service/backend不是pptx-service）。漂掉的后果比想象严重：暖出来的桶与构建期需要的不是同一个东西——CI 全绿，缓存要么永远命不中、要么更糟，命中了但内容不对。
所以改成运行时从
desktop-build.yml正则解析出--service/--src/--requirements再执行。解析不到 4 个就硬失败，两边结构漂了会当场报错而不是静默跑偏。验证
本机干跑解析器，两个平台都正确解析出 4 个服务、
--src全对：合并后这个作业会在 master 上跑一次（约 7 分钟，不阻塞任何人），从那之后的 PR 才开始受益。
🤖 Generated with Claude Code