GitHub Actions 保留策略变更后，Mac CI 审计证据怎么留？2026

先分清保留策略覆盖的证据对象

自 2026 年 10 月 1 日起，GitHub Actions 保留策略开始覆盖检查、工作流运行和提交状态；此前受影响的记录曾不受该设置控制，官方公告说明相关记录按企业、组织或仓库配置的期限清理。此策略也涉及第三方集成创建的相关检查与状态，并非只有 Actions 自身创建的记录。调整期限不会恢复此前已删除的数据。（GitHub 官方变更公告）

这里需要区分“记录”和“文件”。检查与提交状态通常是可关联到提交的结果及来源信息；工作流运行记录承载运行上下文；日志、测试报告、归档包和符号文件则是实际文件。它们在策略中可能受同一个保留设置约束，但“提交状态仍可见”不等于对应日志、构建产物仍可下载，也不等于外部备份里存在可用副本。GitHub 对检查运行记录、提交状态和工作流产物分别提供了对象说明与接口文档。

哪些记录可能随策略自动清理？ 不只构建产物和日志；检查、工作流运行和提交状态也进入保留策略范围。仓库里若有第三方集成写入的检查或状态，也应放进清点范围，不能只盘点 Actions 工作流。

实际审计通常还会遇到三类断点：

• 状态有结论，缺少依据。 提交状态显示成功，却没有可取回的日志、测试报告或构建文件，审计只能看到结论。
• 文件已导出，关联信息丢失。 文件名或目录没有保存仓库、提交 SHA、工作流运行标识和来源集成，之后无法解释文件对应哪次发布。
• 仓库设置看似够长，实际受上级限制。 仓库可以配置自己的期限，但不能突破组织或企业设定的上限；只查看单个仓库页面容易误判有效期限。GitHub 的组织保留设置文档说明了层级约束和设置入口。

Mac CI 审计证据要能从发布结论追到运行

一条可复核的发布证据链，至少要能从发布批准或构建结论定位到提交，再找到对应的工作流运行、检查结果或提交状态，并说明状态由哪个服务或集成创建。若发布系统用第三方集成写入状态，必须把该集成身份和状态上下文一并纳入盘点；否则记录虽在，来源却可能无法辨认。

状态记录与工作流运行记录应怎样归档？ 将它们作为不同对象导出或登记，并保存彼此的关联键。至少记录仓库、提交 SHA、运行标识、检查或状态来源、结论、发生时间以及对应归档位置；团队应按自身审计要求确定具体字段，而不是假设某个统一字段集合就能满足所有审计。

可以用 API 抽查对象是否仍可读取，并将返回的标识写入归档索引。下面的示例只查询对象，不会建立备份：

REPO="ORG/REPO"
SHA="<commit-sha>"
RUN_ID="<workflow-run-id>"

gh api "repos/$REPO/actions/runs/$RUN_ID" \
  --jq '{id, head_sha, head_branch, event, status, conclusion}'

gh api "repos/$REPO/commits/$SHA/statuses" \
  --jq '.[] | {context, state, created_at, target_url}'

gh api "repos/$REPO/actions/runs/$RUN_ID/artifacts" \
  --jq '.artifacts[] | {id, name, expired, created_at, expires_at, digest}'

字段是否出现、权限是否足够、对应对象是否仍然存在，都应以目标仓库的实际响应为准。查询结果不能代替导出，也不能证明目标文件已经成功归档。

用审计窗口复核设置，而不是先填一个统一期限

GitHub 文档指出，保留设置可在组织层级配置，仓库设置受组织或企业上限约束；公开仓库可配置范围为 1 至 90 天，私有仓库为 1 至 400 天，具体还要看管理层级及实际产品设置。文档也说明，修改保留设置只适用于新对象，不会追溯改变既有对象的保留状态；生效后的适用范围与界面配置应在目标组织再次确认。（GitHub 组织保留设置文档）

不应据此直接把某个天数当作企业通用审计期限。安全团队应先明确发布审计窗口、调查需求、合同或内部政策要求，再逐项与当前设置及组织、企业上限比较。若要求的留存时间超过平台允许范围，需安排外部归档，而不是把仓库设置调到上限后就认为问题已解决。

保留期限调整后，已清理的数据还会重新出现吗？ 不会。官方说明，变更设置不会恢复已经清理的数据；若记录已不在平台上，应查找事先建立的外部归档或其他留存记录。

让归档覆盖日志与文件，并把恢复纳入验收

Mac CI 日志、状态记录和构建产物应按对象分开定义保管责任。检查与状态用于说明结果和来源；运行记录用于定位工作流上下文；日志用于调查执行过程；测试报告、应用归档文件和符号文件则是独立的构建输出。GitHub 的工作流日志下载说明提醒，部分重新运行的工作流，下载到的日志可能仅包含重跑的作业；需要完整记录时，必须考虑先前运行尝试的日志。

GitHub 允许为单个产物设置 retention-days，但该值不能超过仓库、组织或企业的保留上限。对于需要超出平台期限保存的对象，应按团队设计的流程导出文件及相关元数据，并以导出记录和索引证明覆盖范围。具体设置与上限可参照前述组织保留文档；不要把平台内的产物期限配置误当成外部归档。

建议按以下步骤落地：

1. 盘点对象。 按仓库、工作流和发布类型列出检查、运行、状态、日志、测试报告、构建归档及符号文件；标记哪些由第三方集成创建。
2. 记录有效策略。 由企业或组织管理员查看上级保留设置与限制，仓库管理员抽查仓库配置；保存设置截图或配置记录，并标注核验时间。
3. 确定审计要求。 由安全或合规负责人确认哪些发布和调查场景必须留证、需要保留哪些字段及文件。将要求与现行策略逐项比对，超出平台期限的对象进入独立归档范围。
4. 建立关联索引。 每次导出时，将仓库、提交 SHA、工作流运行标识、检查或状态来源、文件名、摘要和归档位置写入同一索引记录。不要只用应用版本号或时间戳作为检索条件。
5. 检查导出完整性。 对照 API 清单、运行页面和归档目录，逐项核对文件是否存在、关联键是否齐全、访问权限是否符合企业要求。GitHub 文档说明，删除工作流运行会连带删除关联产物；已删除的产物不能恢复。（GitHub 删除工作流运行产物的说明）
6. 执行恢复演练。 按提交、运行标识或发布版本找回样本，检查文件能否读取、摘要能否复算、索引能否解释其来源及检查结论。记录实际结果、访问角色和未覆盖对象；“已导出”只是动作记录，不是恢复成功的证明。
7. 划定责任并复核例外。 企业管理员负责上级策略，仓库管理员负责仓库配置与抽查，安全审计人员负责需求和访问审查，Mac CI 平台团队负责导出、索引和恢复演练。任何例外都应注明批准人、范围和复核方式。

在 Mac 节点层面，重点不是把远程主机当成证据库，而是确保构建流水线能稳定生成待归档对象，并按既定流程交付。若还在规划专用节点，可结合 Mac 远程算力方案核对访问方式与团队使用条件；NodeMini 提供的是远程 Mac 使用环境，不应被理解为自动归档或合规保证。

用证据矩阵验收覆盖、责任与恢复

下表可作为盘点表的起点。平台内可查到某项记录，不等同于团队已经完成独立归档；“保存位置”和“恢复验证”需要由团队填写真实结果。

CI 构建产物归档怎样与平台记录分开管理？ 以“记录可追溯、文件可取回”作为两项独立验收条件：一项确认检查、状态和运行之间的关系仍可解释；另一项确认日志、测试报告和构建文件已保存且可恢复。不要用一项成功替代另一项。

企业既有 Mac CI 方案可能面临节点维护与容量安排、多人共用时的权限边界、硬件采购后的闲置或扩容压力；这些问题可以通过节点规划或远程使用方式缓解，却不会自动解决证据留存、权限审查和恢复验收。先用证据矩阵检查现有流程，再判断是否需要补充专用 macOS 构建节点。若需要临时或阶段性 Mac CI 环境，可评估 NodeMini 远程 Mac 方案是否符合团队访问与运行要求；长期稳定重负载或依赖本地物理接口的场景，则应先比较自购设备与远程节点的运维边界。无论选择哪种节点，长期审计证据仍需由团队单独归档并完成恢复验收。