Why a green workflow name is not traceability
A volunteer maintains captions for a community museum’s exhibit videos. A pull request changes timing, speaker labels, and accessibility descriptions. The repository has an automated check, but a screenshot saying “caption-check: passed” is weak release evidence: many runs of that same workflow can share the display name. An editor needs to locate the exact event, commit, and test output that was reviewed.
GitHub Actions provides GITHUB_RUN_ID, a unique number for each workflow run within a repository. GitHub documents that the number does not change when that workflow run is rerun. Use it as one part of an audit identifier instead of relying on a job title, a timestamp copied by hand, or the apparent color of a status badge.
Capture the ID from the trusted workflow context
The variables reference lists GITHUB_RUN_ID and shows that a workflow run URL can be built from GITHUB_SERVER_URL, GITHUB_REPOSITORY, and GITHUB_RUN_ID. For a GitHub Enterprise environment, using the supplied server URL avoids assuming github.com. Capture the repository identity and server origin together with the numeric run ID because the ID should not be treated as globally unique across every repository and installation.
The environment variables are operational metadata, not an authorization credential. A workflow log may include untrusted pull request content, so do not concatenate unvalidated branch names into shell commands or public artifact paths. Read event context through trusted workflow expressions where appropriate, and keep permissions on the workflow token narrow.
Distinguish ID, run number, and attempt
GITHUB_RUN_NUMBER increments for successive runs of a particular workflow, whereas GITHUB_RUN_ID identifies a workflow run within its repository. GITHUB_RUN_ATTEMPT starts at one and increments when the same run is rerun. A reviewer deciding whether a failed caption check was later repaired needs the attempt number in addition to the run ID, because both attempts can share the same run ID.
Record these fields in a structured report rather than in a vague filename: server, repository, workflow, run ID, run attempt, event type, commit SHA, and report digest. If a workflow uses pull_request, GitHub documents that GITHUB_SHA can refer to a merge commit depending on the event. Do not assume it is always the contributor’s head commit; capture the relevant tested revision explicitly.
Bind reports to the content actually tested
Create an automated caption QA report that lists each test name, result, detected language, affected media asset, and a digest of the exact caption file. The job should fail when required parsing or accessibility checks fail, rather than producing a cheerful document with hidden errors. Store the Git commit and caption checksum alongside the run identity so a later edit invalidates that evidence.
A video can have technically valid WebVTT syntax while misidentifying a speaker or omitting a safety warning. Automated validation supports the editor; it cannot certify spoken accuracy, translation quality, consent, or timing for a real audience. Keep these as separate human review decisions recorded against the same content revision.
Compare a label, an ID, and a signed-off release
A workflow display name is useful for navigation but is shared by multiple runs. A GITHUB_RUN_ID link narrows the evidence to one execution; the report then needs the run attempt and commit information to identify the exact tested state. An approved release record adds the human reviewer, evidence digest, and publication decision. These are conceptual stages in the accompanying comparison, not screenshots of actual GitHub results.
For example, a caption change might pass on one pull request commit and be edited again before merging. A release checklist should reject the old report when its file hash no longer matches. Avoid copying a run URL into a final release note without checking that it opens to the intended repository and attempt under the reviewer’s permissions.
Expect artifacts to expire
GitHub workflow logs and uploaded artifacts are retained only for configured periods. Documentation provides repository, organization, and enterprise controls, and the upload-artifact action can specify a bounded retention-days value. A durable editorial record should not rely on a downloadable log that may disappear, be deleted with a run, or be inaccessible to a future collections team.
Export a compact approved report to an access-controlled records system with a retention policy suitable for the museum. Preserve the original run URL as a useful pointer, along with the report digest and human approval. Avoid archiving secrets, raw credentials, unnecessary personal data, or an entire repository when only the released caption evidence is required.
Restrict permissions in pull request checks
Caption contributors may submit untrusted content from forks. Run syntax and timing checks in a restricted environment, avoid giving write permissions or production credentials to untrusted pull request code, and review third-party actions before using them. A green GitHub Actions check does not demonstrate that an action itself is trustworthy or that secret handling was safe.
Do not use a workflow triggered by a pull request as a mechanism for directly publishing museum pages without a separate protected review gate. Keep generated artifacts read-only until a trusted release step consumes them. Record the event name and security boundary in the review packet, especially if different event types have different token behavior.
Make the reviewer workflow usable
A reviewer should be able to open the approved caption file, play the media, see the exact CI report, and record corrections without deciphering long internal paths. Show the run URL, the commit reference, the attempt number, and the report summary in one panel. Pair automated checks with a spot-check on real playback, including mobile controls and keyboard accessibility.
If the required artifact is missing or the report has expired, do not replace it with an unverified screenshot. Re-run an approved check against the exact candidate revision, record a fresh attempt or run, and repeat the human review for what actually changed. The audit should state what was checked, not merely what a workflow seemed to do.
Handoff limits and release checklist
Before publishing, confirm run identity and attempt, event type, tested SHA, caption file digest, report validity, artifact retention, review permissions, and the named editor’s sign-off. Keep a withdrawal process if a later accessibility issue is discovered. The run metadata belongs in the private release record, not as a prominent internal ID on visitor-facing graphics.
This guide did not execute a GitHub Actions workflow or test any captions. The figures are instructional designs illustrating GitHub’s documented variables and retention behavior. Check current GitHub plan, runner, actions versions, token scopes, and organizational artifact rules before implementing a production release flow.
How We Research
Official primary documentation reviewed November 11, 2026: GitHub Actions variables reference; GitHub Actions artifact retention guide; GitHub REST workflow runs API. We compared the named technical feature against its provider reference and designed a hypothetical archive workflow covering configuration, risks, error handling, and human authorization. We did not run an API call, inspect a customer account, benchmark software, or verify outcomes in a production environment. Images are editorial diagrams rather than product screenshots or observed results. Confirm current documentation, support, privacy requirements, quotas, costs, and actual deployed settings before making changes.
Frequently Asked Questions
No. RUN_ID identifies a run in a repository; RUN_NUMBER increments within a workflow.
No. GitHub documents that the run ID stays the same; GITHUB_RUN_ATTEMPT changes.
Combine the trusted GITHUB_SERVER_URL, GITHUB_REPOSITORY and GITHUB_RUN_ID values as documented by GitHub.
No. A human still needs to confirm spoken accuracy, timing, safety meaning, and accessibility.
Keep a digest and approved report in a separate authorized records system, subject to the organization’s retention rules.