GitHub扩展Actions记录保留策略：检查与状态也会到期，延长期限不能找回已删数据

前天 3阅读

2026年10月1日，GitHub确认此前预告的Actions保留策略扩展已生效：检查、工作流运行和状态记录，与产物及日志遵循同一保留设置，超过期限自动清理。范围包括GitHub Actions和第三方应用生成的检查与状态，适用于github.com上的Actions。

公开仓库最长保留90天；仓库设置还受组织与企业上限约束。官方特别说明，修改保留期限无法恢复此前已经删除的数据。这里的10月1日是当前适用状态的确认日期，不应被写成该计划首次对外宣布的日期。

链接还在，背后的证据可能已经到期

以下为本文的维护分析。许多团队会在发布说明或故障记录里贴上一次CI运行的链接，认为以后都能回看。保留范围扩大后，需要重新确认这些引用能存活多久。一条备注“当时检查通过”可以保留结论，却未必保留当时检查了什么、使用了哪个环境，以及出现过哪些例外。

可以先从最重要的一类记录开始盘点，例如每次正式发布。列出未来需要回答的问题：对应哪次提交、哪些测试执行过、谁作出发布决定。再决定哪些材料由开发平台保留，哪些需要进入项目已有的长期档案。目的不是无限保存所有日志，而是让必要的解释在合适期限内仍然成立。

AI模型生成的概念示意图，表现记录经过统一保留期限，并非平台截图或实际清理现场。

例如一个外部测试服务把结果写回GitHub，项目成员平时只在PR页面阅读状态。此次公告覆盖这类检查与状态，因此不能只询问Actions工作流的负责人。外部服务是否另存完整报告、链接是否有自己的到期规则，以及需要时谁能访问，都影响未来能否还原一次判断。

一个简单的登记方式，是把“结果摘要”“详细报告”“原始日志”视为三种材料。它们可能在不同地方，也可能有不同保留时间。把负责人与保存位置写在一起，便于后来的人理解：某个链接失效时，是材料按计划到期，还是采集流程出了问题。

仓库管理员看到的值未必能突破组织或企业限制。团队讨论保留多久时，最好同时记录上层约束和实际应用值，并把需要长期追溯的项目交给相应负责人决定。只在某个仓库里填一个更大的数字，不能替代对最终生效范围的确认。

清理之后的报表也要谨慎解读。历史运行数量下降，可能来自保留策略，而不是开发活动减少；某段时期的失败记录缺失，也不能直接解释成那段时间没有失败。趋势分析应保留数据覆盖起止时间，把查询得到的范围和想研究的范围明确区分。

这次变化适合推动一次有重点的整理：保住真正用于发布追溯的材料，为普通调试日志设合理期限，并检查相关文档中的旧链接。完成以后，团队需要的不是更多历史页面，而是一套能解释哪些证据仍然可查的记录习惯。

GitHub保留策略适用公告发布于2026年10月1日，本文于北京时间2026年10月2日核验。后续维护建议为原创分析。