写过 CI 的人都踩过这个坑——把 GitHub Actions 当成永久档案馆，今天这件事要变成明面上的规矩了

写过 CI 的人都踩过这个坑——把 GitHub Actions 当成永久档案馆，跑了三年的工作流日志从来没管过，直到某天要查一次发布事故才发现记录早被悄悄清了。2026 年 10 月 1 日起，这件事要变成明面上的规矩了。

GitHub 在 8 月 27 日宣布，从 10 月 1 日起，checks、workflow runs 和 statuses 三类记录将正式纳入 GitHub Actions 现有的保留设置，和 artifacts、logs 共用同一套清理规则。在此之前，这三类记录的保留期不受你配置的限制，通常会保存 400 多天；新规则生效后，默认保留期统一变成 90 天，超期自动清理。

具体变了什么？

这次调整把五类 Actions 数据绑到了同一套保留设置上：检查结果、工作流运行记录、提交状态、工作流日志和工作流生成的构建产物。之前只有后两者受保留设置管控，前三者可以毫无代价地存活 400 天以上；新规则生效后，五类数据共用同一个过期时间。

保留期有上限。公开仓库最多保留 90 天，和 artifacts、logs 的上限拉平；私有仓库最高可设 400 天，但实际窗口还要看组织和企业的上限有没有更严格的限制。所以只改仓库级设置不一定算数，平台团队还需要核对上级策略。

另一个关键点：这次调整不是追溯性的。10 月 1 日之前因为旧策略已经被清理的数据，不会因为改了设置就复活；10 月 1 日之后调高保留期，也只能影响仍然存在或之后产生的数据。换句话说，事后补救不如提前归档。

对企业的影响

Artifacts 和 logs 是计费的，checks、workflow runs、statuses 的元数据本身不收费。对于那些之前为了控制构建产物占用而主动缩短保留期的团队，这次纳入会按同一周期同步清理运行历史——如果有效设置低于 90 天，新纳入的三类记录不会自动获得完整的 90 天窗口，账单可能降了，历史数据也少了。

对于靠长期运行历史做审计、合规记录或 DORA 指标分析的团队，90 天窗口是个硬约束。想在 GitHub 里面保留超过 90 天的 CI 证据，公开仓库这条路直接堵死了。

现在该做什么

第一，在 10 月 1 日之前查一遍仓库、组织、企业三级的 Actions 保留设置，确认当前配置是否符合团队对运行历史的实际需求。第二，如果需要超过上限的保留窗口，在允许范围内上调；公开仓库最多只能设到 90 天，超过这个时长必须导到 GitHub 外部。第三，把需要长期保存的运行记录、工作流运行结果和检查状态导出到外部存储或专门的审计系统。第四，这次变更是平台级的数据治理变化，建议通知安全团队和合规团队，让他们评估是否需要调整内部审计流程。

简单说就是：10 月 1 日之前，你需要明确回答一个问题——哪些 CI 信息只服务于近期开发，哪些必须进入长期可检索的发布或审计系统。答案不同，处理方式也不同。