After GitHub Actions Retention Policy Changes, How to Keep Mac CI Audit Evidence? 2026

What GitHub Actions retention now covers for Mac CI audit evidence

GitHub announced that, effective October 1, 2026, retention settings also apply to checks, workflow runs, and commit statuses. The announcement includes relevant records created by third-party integrations, so an audit inventory limited to Actions-created checks can miss evidence tied to the same commit. Review GitHub’s retention change announcement.

This changes what teams should verify; it does not make every evidence type interchangeable. A check or status is metadata about a result. A workflow run records execution context. Logs provide details about what happened during execution. Artifacts are files produced by a workflow. A retained status does not prove that a build archive or its logs remain downloadable.

Use the official API references to identify which records your pipeline creates: check run records and commit status records. Treat checks created by integrations as part of the same evidence review, even when a separate system originally produced them.

A simple inventory query can help platform teams check whether the identifiers needed for an audit can still be found. Replace the placeholders with approved values and use an access token permitted to read the repository’s records.

gh api "repos/OWNER/REPO/commits/COMMIT_SHA/check-runs"
gh api "repos/OWNER/REPO/commits/COMMIT_SHA/status"

The response should be treated as a discovery result, not as an archive or a recovery guarantee. A check or status response can help locate related evidence, but it does not establish that logs or artifact files are still available.

Traceability: connect a release decision to its source records

A release approval is only auditable when the team can explain which code and CI result supported it. For each release conclusion, define the links an auditor should be able to follow: the repository and commit, the workflow run, relevant checks, status contexts, and the identity or integration that produced each result.

Do not rely on a green status alone. The status API describes commit status records, while check runs are a distinct record type with their own details. GitHub’s documentation for commit statuses and check runs can help teams distinguish those sources when building an evidence map.

For each release path, document:

• Which check names and status contexts count as required release evidence.
• How each record is tied to a commit and workflow run.
• Which integration or automation created the record, including third-party integrations.
• Whether a release approval is stored in the same system as the CI evidence or must be linked separately.
• Which evidence must be preserved to explain an exception, rerun, or failed build.

This is especially important when a pipeline combines a Mac build with external review or deployment steps. The Mac job may produce a test report and archive, while a separate integration reports a commit status. If those records are not indexed together, an auditor may see a successful result without being able to determine what was built, which run produced it, or what evidence supported approval.

A compact evidence manifest can preserve the relationships without pretending that metadata is the underlying file:

{
  "repository": "OWNER/REPO",
  "commit": "COMMIT_SHA",
  "workflow_run": "RUN_ID",
  "checks": ["CHECK_NAME"],
  "status_contexts": ["STATUS_CONTEXT"],
  "artifact_refs": ["ARCHIVE_REFERENCE"],
  "evidence_owner": "TEAM_OR_ROLE"
}

The values above are placeholders. Store only fields approved by your security and retention policies, and verify that each reference resolves to accessible evidence.

Retention fit: compare effective policy with audit and investigation needs

Do not assume that a repository administrator can set any retention period the team needs. Review the applicable enterprise, organization, and repository controls, then confirm which setting actually governs the repository. GitHub documents organization-level configuration for Actions artifact and log retention; review the organization retention settings and their limits alongside the settings visible in the target organization.

The effective value matters more than a screenshot of a repository preference. An upper-level policy can constrain a lower-level setting. Record both the configured value and the limit imposed by the controlling scope; do not treat a repository setting as proof that the organization allows that period.

Next, compare the effective policy with the actual requirements for each evidence class. Audit windows and incident-investigation needs differ by organization and obligation, so there is no universal period to copy into every repository. Have the relevant security, legal, and platform owners identify the required window for their records, then document where the current configuration falls short.

Follow this review sequence:

1. Inventory the organizations, repositories, workflows, and integrations that create release evidence.
2. Read the applicable enterprise and organization controls, including any policy that limits repository-level choices.
3. Inspect the effective setting on representative repositories and confirm it matches the inherited or controlling policy.
4. Map checks, runs, statuses, logs, and artifacts to the team’s audit and incident-investigation requirements.
5. Identify evidence that must outlast the platform’s effective retention behavior and assign it an independent archive route.
6. Record exceptions, approvers, review ownership, and the date when the configuration will be checked again.

Keep the configuration record with the evidence review, but do not make it the only proof that the policy works. A policy screenshot documents an observed setting. It does not prove that a particular run, check, status, log, or artifact was retained or can be restored.

Recovery: prove archived evidence can be found and read

For Mac CI audit retention, exporting files is only one part of the control. A recovery test should show that a person with the approved role can locate evidence using a commit, workflow run, or release reference, open the retrieved files, and explain how those files relate to the release decision.

Separate the responsibility for platform records from the responsibility for files. GitHub’s documentation describes workflow artifacts as files associated with workflow execution. Logs have their own retrieval path, described in GitHub’s guide to downloading workflow run logs. These sources help establish what the platform exposes; they do not prove that your organization has an independent archive or that a particular export can be restored.

For each evidence class, make the recovery test answer these questions:

• Can an authorized reviewer retrieve the record or file from the index?
• Can the reviewer associate it with the intended commit, run, and release?
• Is the content readable and complete enough to support the audit purpose?
• Are access controls appropriate for the file and its sensitivity?
• Does the archive record show where the evidence came from and when it was captured?

Apply the same standard to files that the platform later removes. GitHub documents how to remove workflow run artifacts; teams should therefore distinguish a platform artifact’s presence at one point in time from an independently retained copy. Avoid declaring an export “recoverable” until a controlled test retrieves and verifies it.

A workable test starts with a known release reference and follows the index to the relevant status, check, run record, logs, and build files. Record which items were found, who could access them, and whether the relationships between them remained clear. If an item is missing, record that as a failed control or evidence gap; do not infer successful recovery from a successful export job.

Ownership and acceptance: make the control reviewable

A retention change crosses administrative boundaries. Assign a named role to each action so that a missing export or ineffective setting does not become an unowned platform problem.

• Enterprise administrators document policy boundaries that affect lower-level settings.
• Organization administrators verify organization configuration and communicate its effective limits.
• Repository administrators check local configuration and identify workflows or integrations that generate evidence.
• Security and audit owners define required evidence, access expectations, exception approval, and review criteria.
• Mac CI platform owners maintain the evidence manifest, export route, artifact handling, and recovery test.

An acceptance package should include the effective configuration record, the evidence inventory, the archive index, access-review results, and the latest recovery-test outcome. Keep a clear distinction between observed configuration and tested behavior: the former shows what was set; the latter shows what a reviewer could actually retrieve.

If a team is separately assessing its hosted build environment, NodeMini’s remote Mac options can be evaluated as Mac infrastructure for CI workloads. That decision should remain separate from evidence retention: a build node can run jobs, but it does not by itself archive checks, statuses, logs, or artifacts.

Decision matrix: platform retention or independent archive

Use this matrix to decide whether the platform alone is sufficient for a record or whether your team needs a separately managed copy. The correct choice depends on your documented audit and investigation requirements, not on a default number of days.

The matrix is a decision aid, not a promise that any platform or archive meets a particular compliance requirement. Define the required evidence with the organization’s responsible policy owners and verify the actual retention and access behavior in the target environment.

FAQ

Which GitHub Actions records can be automatically removed?

Since October 1, 2026, GitHub’s announced change includes checks, workflow runs, and commit statuses under Actions retention settings, including relevant records created by third-party integrations. Logs and artifacts also need separate review. Inventory the record types individually; the existence of check metadata does not establish that its log or downloadable build file is still available.

How can teams keep statuses and workflow runs as audit evidence?

Capture the commit, run, check, status context, and source integration needed to explain the release decision. Export required records under an approved process, keep logs and artifacts as separate evidence classes, and index them by commit or release. Then have an authorized reviewer retrieve the archive and verify that its contents and relationships are understandable.

Can a longer retention setting bring back deleted checks or runs?

No. A changed setting does not recreate data already deleted under the previous policy. Search approved exports or other independent archives for the missing evidence, record any gap, and apply the corrected policy going forward. Do not report the setting change as a recovery action unless the original records have actually been retrieved and verified.

How should teams archive Mac CI logs, statuses, and build artifacts?

Assign separate handling to each type: statuses and checks support the decision trail, run metadata and logs explain execution, and artifacts preserve produced files such as reports or release archives. Record an owner, source, access rule, and recovery check for each. Test retrieval from a commit or release reference rather than relying on a successful export notification.

Start by using the matrix to check whether the existing evidence trail has an owner, an archive route, and a tested recovery path. If the team also needs a dedicated macOS build node, assess access controls, operational ownership, and the build workload separately; a remote Mac is compute infrastructure, not an evidence archive. For temporary or variable Mac CI capacity, review NodeMini’s remote Mac options alongside the existing setup. Renting can avoid assigning every developer a dedicated Mac and reduce the burden of maintaining an additional in-house node, but it does not solve fragmented access policies, archive design, or audit obligations. Teams with sustained heavy workloads or a requirement for physical interfaces should compare rental with owned hardware before deciding. NodeMini can provide the Mac environment; the organization remains responsible for preserving and verifying its CI evidence.