Actions 保留策略将涵盖检查、工作流运行和状态

事件核心：发生了什么

GitHub Changelog 于 2026 年 8 月 27 日发布公告，称自 2026 年 10 月 1 日起，GitHub Actions 的保留设置将全面适用于 checks（检查）、workflow runs（工作流运行）和 statuses（状态）。此前，这三类数据无论仓库如何配置保留策略，都会被存储 400 天以上；而 artifacts（构件）和 logs（日志）早已遵循默认 90 天的保留周期。调整后，上述五类数据将统一由同一保留策略管理，超过仓库、组织或企业配置期限的数据会被自动清理。界面中的设置标签也将同步更新为“Check, workflow run, status, artifact and log retention”，以反映其管理范围的扩大。

值得注意的是，此次变更不追溯历史数据，调整设置不会恢复此前因超期已被清除的数据。对于公开仓库，checks、workflow runs 和 statuses 的保留上限与 artifacts、logs 一致，均为 90 天；私有仓库则可依据组织或企业层级的封顶值上调保留期限。

为什么重要

这一改动直接影响 GitHub Actions 的数据生命周期管理。过去，checks 和 workflow runs 等元数据长期滞留，累积成大量陈旧数据，增加存储负担并拖慢接口响应。统一保留策略后，GitHub 能系统性清理冗余信息，使 Actions 的查询、状态展示和工作流历史保持轻量高效。对依赖 CI/CD 的 AI 工程团队而言，这还关系到可观测性与审计追溯的平衡：模型训练、推理任务或数据处理管线的执行记录若被过早清理，可能影响问题排查和合规审查。同时，GitHub 明确 artifacts 和 logs 仍计入可计费的 Actions 存储空间，而 checks 等元数据本身不收费，因此该策略调整在控制存储成本的同时，也间接影响了企业按量付费的账单结构。

对用户/开发者/创作者的影响

对大多数开发者而言，无需立即采取行动，但需要在 10 月 1 日前重新审视自己的保留配置。如果工作流中依赖长时间保留的检查记录或运行状态（例如用于审计、模型复现或发布追溯），建议提前导出或归档所需数据，并评估是否需要调高保留期限，但需注意公开仓库上限为 90 天。对于企业或组织管理员，应检查组织级与仓库级的保留封顶设置，确认其与内部数据合规要求匹配。如果当前配置的保留周期过长，调低后可从两方面获益：一是减少 Actions 存储费用，因为 artifacts 和 logs 会更快被清除；二是降低数据量，提升 UI 和 API 的检索性能。反之，若调高保留期，则需接受存储成本上升的潜在代价。

AI 工具推荐

想把多个 AI 模型放在一个入口？

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。

值得关注的后续

首先，观察 GitHub 是否会在实施后发布保留策略清理的透明化报告，例如展示清理数据量与系统性能提升的对比，供企业用户评估效果。其次，留意组织与企业级封顶策略是否随此次变更调整，尤其是私有仓库的长期保留上限是否可能在未来放宽。此外，竞品平台（如 GitLab CI、CircleCI）是否跟进类似的数据生命周期管理策略，也值得关注——若行业普遍收紧历史记录保留期限，开发者在设计长期持久化的工作流审计方案时，可能需要更多依赖外部归档工具或自建日志系统。

来源：GitHub Changelog