Why passing CI is not a durable audit trail
A museum website may use GitHub Actions to test subtitle timing, alt text, broken links, and caption file syntax before releasing a new exhibit. A green workflow badge is useful at the time of deployment, but it is not a permanent collection of evidence. GitHub Actions logs and uploaded artifacts have configurable retention periods. GITHUB_RETENTION_DAYS is a runner-provided environment variable describing how long those logs and artifacts are kept for the relevant workflow context.
If a curator asks six months later which caption file passed review, expired logs may no longer be available. Build an audit process that saves a small approved release record outside transient workflow storage. Keep the record tied to the specific file hash and commit rather than assuming today’s workflow output describes an earlier published version.
Read the runner variable without confusing it with policy
GitHub documents GITHUB_RETENTION_DAYS among its default environment variables. A script step can read the value to annotate a QA report or decide whether to create a longer-lived approved record. It cannot change the organization’s retention limits by assigning a new shell value. Default environment variables belong to the runner context; do not mistake them for editable workflow configuration or a guaranteed deletion date for each file.
Capture the reported value together with repository identity, workflow name, run ID, run attempt, and commit SHA. These provide more reliable provenance than a label such as latest-caption-check. The numerical value tells a pipeline the general retention window, but administrators may have configured ceilings or changes. Verify actual artifacts in the repository and use the API when an exact expiration time is important.
Understand where retention limits come from
GitHub repository settings can configure the retention of workflow artifacts and logs, subject to organization or enterprise restrictions. The public-repository and private-repository limits described in current documentation differ, and a setting change generally applies to new items rather than retroactively changing existing ones. Avoid copying a single retention number into every project or promising a fixed history window for all repositories.
A specific artifact uploaded by a workflow can have its own retention setting within the allowed policy. The workflow still cannot exceed an administrator’s maximum. A separate archival repository or records system may be necessary when institutional retention policies outlast GitHub Actions storage. Approval to keep a record also requires privacy and intellectual property review.
Decide what caption evidence is worth keeping
Most audits need the version of the caption asset checked, the validator version, the rule set, a short pass/fail summary, the approving reviewer, and links to the approved source material. They rarely need the full runner debug log or a copy of every transcript. Create a compact machine-readable release manifest and a human-readable summary; do not treat automatically generated warnings as resolved simply because a workflow succeeded.
A useful manifest records the caption filename, SHA-256 digest, language code, timing validator version, and review decision. A private catalog can connect that digest to a stored source file. Do not publish sensitive interview text to a public Actions artifact, where repository access and retention policies might be broader than the interview release agreement.
Keep artifacts, logs, and approvals separate
A workflow log records command execution and errors. An uploaded artifact can preserve generated reports or processed files. A curatorial approval is a distinct institutional action. These three objects have different ownership and retention needs. The absence of a log after expiration does not prove that QA was never performed; conversely, an uploaded report is not evidence that an authorized person approved its conclusions.
Model three states in the release dashboard: a temporary run report, an artifact with a known retention window, and a signed or access-controlled release record. An audit should be able to reach the last state even after the first two expire. The examples in the accompanying diagram show conceptual states, not artifacts retrieved from a repository.
Check the exact artifact expiry when necessary
GitHub documents an expires_at value through the artifacts REST API and provides ways to inspect or remove workflow artifacts. When a project must prove when a report will disappear, prefer that specific metadata over adding a duration to the time a workflow started. Upload time, retention configuration, and later administrative action can affect the actual artifact lifecycle. Respect API pagination and the permissions of the token that reads the record.
Do not build an automated deletion or archival job that downloads all workflow artifacts without regard to access permissions. Limit queries to a particular approved repository and report class, validate checksums, and restrict storage. If a record is already expired, flag the gap rather than creating a replacement that pretends to be the historical original.
Test re-runs and changed caption files
A workflow run ID can remain the same across attempts, while run attempt increments. Preserve both fields to distinguish an initial failure from a corrected execution. If caption content changes between attempts or commits, tie the evidence to the exact checked SHA and file digest. A new artifact named caption-report is not sufficient provenance if its underlying input differs.
Use a fixture in which an invalid timing overlap fails once and a corrected subtitle file passes on a later run. Confirm that the dashboard shows both outcomes and that only an authorized review of the corrected version can permit release. Do not auto-publish because an old green result exists for a different file or because the new run used an inherited artifact name.
Respect privacy while making evidence accessible
Caption QA for oral histories can include personal names, unfinished translations, or material that the speaker has not approved for public release. Store the minimal evidence needed to demonstrate an accessible check. Avoid uploading complete private captions as workflow artifacts solely for convenience. Prefer a checksum and a controlled reference to an approved content store, with separate permission checks for staff and public visitors.
If a reviewer needs to see a disputed line, use a restricted review surface with a documented retention rule. Do not rely on log expiration as a substitute for safe data handling; material copied to external storage can persist longer. A release policy should explain who can access the evidence and how corrections are linked to prior public versions.
Pre-release checklist and known limits
Verify the value exposed by GITHUB_RETENTION_DAYS, repository and organization limits, artifact-level retention options, a precise expiration source where needed, and a separate records location. Confirm that reviewer approval and checked file hashes are captured before deployment. Review the audit process after changing your workflow or GitHub subscription policy.
No repository or caption CI job was run in preparing this article. The sample release flow is a design example, not evidence of a successful accessibility audit. GitHub can change platform limits, variable documentation, storage pricing, and API capabilities, so check official guidance for the target repository.
How We Research
Official primary documentation consulted November 11, 2026: GitHub Actions variables reference; GitHub repository Actions settings; GitHub workflow artifact retention guide. We compared the named API or runner setting with the provider documentation and designed a hypothetical museum workflow to expose failure states, permissions, data provenance, and release checks. We did not call a production API, query a customer account, execute a live workflow, or measure performance. The accompanying illustrations are editorial diagrams, not screenshots or experimentally observed outcomes. Confirm current versions, supported features, charges, privacy rules, and organizational authorization in the real deployment before relying on this guide.
Frequently Asked Questions
No. It reports a runner environment value; repository, organization, enterprise, and allowed artifact settings control retention.
No. GitHub Actions logs are subject to retention and deletion rules, even when a workflow completed successfully.
GitHub documents the expires_at field in its artifacts REST API for checking a specific artifact.
Keep the input file checksum, commit SHA, workflow run ID, and attempt number alongside the validator version.
No. A test report and an authorized review decision are different records and should be retained separately.