A GitHub Actions Cache Key Is Not the Cache Key

A four-month CI performance issue was traced to GitHub Actions cache entries silently failing to restore because cache addresses depend not only on the visible key but also on an internal version incorporating the runner’s compression tool. GitHub-hosted cache-writing jobs used zstd while self-hosted test jobs lacked it and used gzip, causing identical cache keys to resolve to incompatible entries; restores reported ordinary “Cache not found” messages and exited successfully. Without the cached pytest duration data, tests were divided by count rather than expected runtime, intermittently leaving some shards far slower and causing timeout failures. The team resolved the mismatch by installing zstd on self-hosted runners and moving cache-writing jobs onto the same runner fleet as readers, while noting that enabling fail-on-cache-miss would have exposed the issue immediately. Early results showed no further timeout-killed shards, illustrating that successful CI checks do not necessarily confirm that caches are functioning as intended.

No tracked trend matches for this post yet.

Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.