很多团队把 GitHub Actions 当成一条只负责通过或失败的流水线，却忽略了它同时也是项目的历史记录。一次检查失败的日志、一个工作流的运行结果、一条提交状态，往往会在几周后成为排查回归问题、复盘发布事故或确认变更范围的证据。
8 月 27 日，GitHub 宣布了一项会改变这套历史记录生命周期的调整。从 2026 年 10 月 1 日起，检查结果、工作流运行记录和状态将跟随 Actions 中已经用于日志与构建产物的保留设置清理。此前，这三类记录通常会保留 400 多天，不受仓库中日志和构建产物保留期的影响；新规则的默认保留期是 90 天。
这不是一个需要立刻修改每个工作流的语法变更，却是一次值得提前处理的数据治理变化。团队需要重新回答一个问题：哪些 CI 信息只服务于近期开发，哪些信息必须脱离 GitHub Actions，进入长期可检索的发布或审计系统。
这次调整具体改变了什么
GitHub 的公告给出了四个关键点。
五类数据将使用同一个保留设置
新的设置会同时覆盖以下内容：
- 检查结果，包括代码检查和测试检查的结果；
- 工作流运行记录；
- 提交状态；
- 工作流日志；
- 工作流生成的构建产物。
之前的设置主要控制日志和构建产物，而检查结果、工作流运行记录和状态可以保留 400 多天。10 月 1 日之后，超过仓库、组织或企业级配置保留期的相关数据，会按照同一套规则自动清理。GitHub 也会更新设置页面的名称，让它明确反映这五类数据的范围。
仓库设置仍然受组织和企业上限约束
保留期不是仓库管理员想设多久就设多久。仓库可以提高自己的保留期，但不能超过组织和企业层面设置的上限。对于公开仓库，检查结果、工作流运行记录和状态的最长保留期是 90 天，与日志和构建产物的现有限制保持一致。
这意味着公开项目不能把 GitHub Actions 当成永久的 CI 归档库。如果项目需要保存超过 90 天的发布证据、测试趋势或合规记录，就要在保留期到达之前导出到其他存储或专门的分析系统。
这次清理不会追溯恢复数据
公告明确说明，这项变化不是追溯性的。调整保留设置不会恢复已经因为旧策略被清理的数据，也不会把过去缺失的检查记录重新补回来。
因此，团队在 10 月 1 日之前导出需要长期保存的内容，比事后尝试寻找旧运行记录更可靠。尤其是已经关闭的拉取请求、历史发布和偶发失败，它们通常不会在日常开发中被及时整理。
存储计费只涉及其中两类数据
检查结果、工作流运行记录和状态的元数据本身不计入 Actions 存储费用，但与它们关联的日志和构建产物会计入可计费的 Actions 存储。保留期缩短后，过去长期积累的日志和构建产物可能更快清理，从而降低存储用量；如果把保留期调长，存储费用也可能随之增加。
这里要区分两个概念：数据能不能在页面上查到，和数据是否占用存储空间，不是同一件事。新的生命周期规则同时影响可见性和存储管理，但计费仍主要落在日志和构建产物上。
为什么 CI 历史记录值得单独规划
开发阶段的 CI 记录通常有很短的使用周期。一次代码格式检查的日志，可能只需要保留到拉取请求合并；一次依赖升级的测试结果，可能在几个版本之后就没有多少价值。
发布和运维场景则不同。下面几类问题经常需要回看较久以前的流水线信息：
| 场景 | 需要回答的问题 | 适合保留的证据 |
|---|---|---|
| 回归排查 | 哪个提交开始出现失败，失败发生在哪个步骤 | 提交、检查名称、失败摘要和关键日志 |
| 发布追踪 | 某个版本使用了什么代码和构建环境 | 提交 SHA、版本号、构建元数据和产物摘要 |
| 依赖审计 | 某段时间内项目是否完成过安全检查 | 检查结论、依赖快照和扫描时间 |
| 测试趋势 | 哪些测试持续变慢或不稳定 | 测试名称、耗时、失败率和时间序列 |
| 事故复盘 | 自动化流程当时做了什么 | 工作流版本、输入参数、关键输出和人工处置记录 |
这些信息不一定要把完整日志永久放在 GitHub 上。更合理的做法，是保留一份短而稳定的摘要，把大体积日志、测试报告和发布包存到与用途匹配的系统中。CI 页面适合近期协作，长期分析则应该有自己的数据入口。
从“保留天数”转向“数据分层”
这项变化最值得借鉴的地方，是它提醒我们不要用一个数字处理所有 CI 数据。可以先把流水线输出分成三层。
第一层是临时反馈。比如代码格式检查、普通单元测试和开发分支构建，它们主要帮助当前拉取请求快速迭代，保留 30 到 90 天通常已经足够。具体天数仍应结合项目节奏和仓库策略确认。
第二层是工程证据。集成测试、性能基准、安全扫描和生产构建，需要在较长时间内支持排障和比较。除了让 Actions 保留近期记录，还应该把结果中的提交 SHA、工具版本、运行参数、检查结论和关键摘要写入可检索的存储。
第三层是发布与合规档案。正式发布包、依赖清单、签名信息和审批记录，不应只依赖 Actions 运行页面。它们应该进入版本仓库、制品库或专门的归档系统，并明确保留周期、访问权限和删除规则。
分层之后，Actions 的保留设置就不再承担所有历史管理责任。它负责近期开发反馈，其他系统负责长期证据，数据使用者也更容易找到适合自己的入口。
对现有工作流的三个影响
旧的失败记录可能比预期更早消失
如果仓库当前设置的日志和构建产物保留期低于 90 天，那么 10 月 1 日后，相关检查结果和工作流运行记录也会按照这个更短的周期清理。团队不能只看页面上默认显示的数字，还要确认仓库、组织和企业层面最终生效的配置。
对经常处理长期支持版本的项目来说，这个变化尤其明显。维护者可能在几个月后收到一个回归报告，却已经无法从 Actions 找到当时的完整执行记录。此时，提交历史只能告诉你改了什么，不能告诉你当时的构建环境和测试输出。
发布流程要保存可验证的构建信息
长期发布追踪不应依赖一个可能过期的工作流页面。每次正式构建至少可以记录以下信息：
1 | 版本号 |
这些字段比一份完整的终端日志更适合长期查询。需要深入排查时，再根据摘要中的运行编号、提交和产物标识寻找可用的详细资料，或从外部归档中恢复。
测试趋势不能只靠回看工作流页面
如果团队想观察测试耗时、失败率或不稳定测试，定期读取 Actions 运行页面并不是长久方案。数据超过保留期后，历史样本会断掉；即使记录仍在，按页面逐条查看也不利于统计。
更稳妥的做法是在工作流结束时输出结构化测试结果，提取测试名称、耗时、失败原因、提交 SHA 和运行时间，再写入指标系统或对象存储。Actions 负责触发和执行，趋势系统负责长期聚合。
10 月 1 日前可以做什么
这次变更距离生效还有一段时间，建议按项目重要程度分批处理。
- 盘点依赖历史记录的流程。 找出需要回看超过 90 天的发布、审计、长期支持和测试趋势场景，记录它们依赖的是检查结果、日志还是构建产物。
- 查看最终保留设置。 分别检查仓库、组织和企业配置，确认实际保留期以及上层策略是否覆盖了仓库设置。
- 导出重要历史证据。 对已经关闭的发布和关键版本，提前保存提交 SHA、检查结论、测试摘要、构建产物摘要和必要日志。不要只保存一个可能失效的网页链接。
- 修改发布流水线。 让正式构建把版本、提交、依赖和产物摘要写入制品库或发布记录，保证未来即使 Actions 页面过期，仍能验证构建来源。
- 验证清理后的体验。 可以在非关键仓库中使用较短保留期进行观察，确认团队需要的信息是否都已经进入长期存储，再决定是否调整正式仓库策略。
如果某些资料需要保留超过公开仓库允许的上限，就不要把希望寄托在把仓库设置调到最大。提前归档才是可控的方案。
一项看似运维、实则影响开发体验的变化
GitHub 这次公告没有引入新的工作流语法，也不会改变一次构建怎样执行，却会改变开发者几个月后还能看到什么。CI 系统的价值不只在于给出当前结果，也在于为之后的排障、发布和复盘留下可用证据。
对个人项目，默认保留期可能已经够用；对长期维护的开源项目、企业服务和有审计要求的系统，应该把 Actions 当作短期执行平台，而不是唯一的历史数据库。把近期反馈留在 GitHub，把长期证据写进合适的归档系统，才能在存储成本、页面可用性和追溯能力之间取得平衡。
结语
从 2026 年 10 月 1 日开始，GitHub Actions 会让检查结果、工作流运行记录和状态跟随日志、构建产物一起进入保留周期。默认 90 天并不一定不够，但它迫使团队重新区分临时反馈和长期证据。
真正需要提前做的，不是盲目把所有保留时间调长，而是列清楚哪些信息会在未来被谁使用、需要保存多久、应该由哪个系统负责。这样，即使 Actions 清理掉旧页面，项目仍然保留能够解释一次构建和一次发布的关键事实。