你以为 CI 跑完就算数了？今天 npm provenance 把这件事彻底透明了

写过 CI 的人都踩过这个坑——某天查历史记录发现 workflow 跑过某 commit，但点进去发现 run 已经不存在了。10 月 1 日之后，这件事会变得更普遍。GitHub Actions 的供应链从来不是你自己管的。

今年 8 月 27 日，GitHub 宣布从 2026 年 10 月 1 日起，checks、workflow runs 和 statuses 的保留期将与 artifacts 和 logs 统一管理，默认 90 天。此前这三类 metadata 可以保留 400 天以上，与你配置的 retention 设置无关。

真正的问题是供应链安全

npm provenance、GitHub artifact attestations 和 SLSA generators 都在验证时依赖 github.com/{org}/{repo}/actions/runs/{run_id} 这个 URL。run 被清理后，这个 URL 就失效了，attestation 变成一张无法验证的空头支票。

这不是假设场景，而是已经存在的问题——社区在 2024 年就有人在讨论这个，只是 10 月 1 日之后会有更多仓库撞上 90 天这个上限。

为什么 GitHub 要改

官方说法是减少 stale data，让 checks、workflow runs 和 statuses 保持快速可靠。对多数仓库来说确实不需要操作，默认 90 天够用。

但如果你把 GitHub Actions 当成发布记录、审计证据或 DORA 指标的数据源，就需要重新回答：哪些 CI 信息只服务近期开发，哪些必须进入长期可检索的系统。

三步下一步

第一步：10 月 1 日前检查 Settings → Actions → General 的 retention 设置，确认是否需要超过默认的 90 天。公开仓库上限 90 天，私有仓库最高 400 天。

第二步：跑一个导出脚本把你需要保留的 run metadata 存到仓库外面。API 有个坑：GET /actions/runs 每次最多返回 1000 条，但 total_count 会报告真实数量，差值就是超限的量。

第三步：如果你依赖 attestation 做供应链验证，考虑把 SLSA 证明存到一个独立的地方，而不只是依赖 GitHub 的 run URL 能访问。

这件事本质上是说：GitHub Actions 是一个 CI 平台，不是一个供应链证据库。如果你的安全模型建立在「GitHub 上跑过就算数」之上，现在是重新审视这个假设的时候了。