A passing caption check needs a reproducible tool
A small museum checks captions for an orientation video in GitHub Actions. The report says the validator passed, but the action running that check was referenced by a mutable version tag. Months later, repeating the workflow may execute different code even though the log still displays the same tag.
The practical question is which validation code was actually used, under which repository revision and run. A successful badge or a friendly action name is not a reproducible artifact by itself. Store a clear chain from video source to caption file, action code and human review decision.
Use the action_ref context in the right place
GitHub documents github.action_ref as the ref of the action being executed for a step executing an action. A value might be a version tag such as v2. It is not the current workflow branch, the caption file revision or proof that a vendor repository remained unchanged.
The contexts reference states that github.action_ref should not be used directly in the run keyword. For composite actions, refer to it through the env context as documented. Do not invent a universal GITHUB_ACTION_REF environment variable if your workflow only exposes the context value in the supported expression location.
Record the repository together with the ref
The same ref string can exist in many repositories. Pair github.action_ref with github.action_repository where available, then add the workflow repository and current source SHA. These fields answer different questions: which action was called, what identifier it used and which revision of your own captions triggered the check.
An audit row that only says v2 is ambiguous. A better record includes the owning organization, action repository, configured ref, resolved commit if established, job/run reference and output artifact digest. Treat the resolved commit as verified only when a trusted source or the execution environment actually supplies that evidence.
Understand a tag versus a commit pin
A tag is a convenient moving or replaceable name depending on repository controls. A full commit SHA identifies a particular Git object. GitHub security guidance recommends pinning third-party actions to a full-length commit SHA for stronger supply-chain assurance.
Do not imply that recording github.action_ref automatically resolves a tag to an immutable action revision. The ref is what was requested, not necessarily the complete code provenance needed for an audit. If policy requires immutable dependencies, pin or independently record and verify the exact revision using trusted repository evidence.
Give the caption checker a stable step identity
A workflow may run several actions with similar names: download source, validate WebVTT timestamps, inspect contrast and upload reports. Give each important check an explicit step id and record its function in the release manifest. The step identity helps staff understand which evidence belongs to which check.
Step identifiers do not establish whether a validator is reliable, and an automatically generated action name may shift when a workflow is edited. A clear report links source video revision, caption language, checker implementation, run attempt and outcome. Keep the report digest stable even if the workflow UI is reorganized.
Compare three different evidence states
The visual comparison shows a declared moving tag, a recorded ref with repository context and a pinned revision tied to a saved caption report. These are conceptual states: no GitHub jobs were executed to generate the diagrams. The distinctions matter because traceable names and immutable executable versions are not the same thing.
A workflow can use a pinned action and still produce misleading results if the checker ignores a language file or swallows errors. Conversely a well-written check using a tag can be accurate on a particular run but harder to reproduce later. Keep both dependency integrity and the substance of each caption test in the review.
Capture the right artifact and source revision
A caption report should include the original media identifier, locale, checked file checksum, ruleset version, action repository and ref, and run or attempt identifiers. Use organization-approved storage with a retention period that allows reviewers to investigate a later correction.
Do not store private speaker transcripts in a public artifact merely to simplify debugging. A digest and controlled record reference may be sufficient. Where a report includes sample caption text, review its access controls and deletion policy. The provenance log should support traceability without creating a second uncontrolled transcript archive.
Consider forks and untrusted pull requests
Pull requests from external contributors may execute with different trust assumptions. Avoid exposing write tokens or archival secrets merely because a workflow calls a familiar action. Follow GitHub guidance on permission minimization, careful event selection and dependency pinning.
A contributor could change a caption file, workflow or test fixture in ways that make a passing check less meaningful. Establish protected review for modifications to the validation workflow itself. The final public release should require a reviewer who can inspect both the caption content and the independent accessibility result.
Build a non-sensitive reproducibility exercise
Use a fictional two-minute tour video with intentionally malformed timing, missing speaker identification and line-length exceptions. Capture the checking action reference and report digest for each run. Change the caption file and test that the recorded source checksum changes while the chosen action revision remains explicit.
Also test that the report is not silently reused when the action reference changes. A workflow matrix can compare two approved versions in a controlled branch. Do not publish the experiment as benchmark data unless the code, environment, fixtures and actual results were recorded and independently reviewed.
Sign off with both machine and human evidence
For public accessibility claims, require a reproducible action revision, stored test artifact, source version, manual caption review and accountable approval. Technical traces identify how a check ran; they cannot judge every nuance of sound, speaker identity or the accuracy of a museum-specific proper noun.
We reviewed GitHub official references and a hypothetical caption-production case. We did not execute GitHub Actions, inspect a real third-party action, audit repository protections or measure accessibility results. Confirm action context behavior in the actual workflow design before treating the report as release evidence.
How We Research
Our November 11, 2026 desk review consulted the following named primary vendor documentation: GitHub Actions contexts reference; GitHub Actions variables reference; GitHub secure use reference. We compared documented fields and failure semantics with a fictional museum workflow, distinguishing request-level facts from institutional approval decisions. The illustrations are original instructional graphics, not screenshots or observed service outputs. We did not execute API calls, access real museum records, run security or accuracy benchmarks, measure performance, or claim an actual success rate. Recheck version-specific service behavior, accounts, privacy, rights and independent source records before deploying a real workflow.
Frequently Asked Questions
For an action step, it identifies the ref of the action being executed, such as a tag or commit reference.
No. github.ref describes the triggering workflow reference; github.action_ref relates to the particular action step.
The documented contexts guidance says no. In composite actions, pass it via env where supported.
No. A tag is not a guarantee of immutability. Prefer trusted full commit SHA pinning and verified provenance where required.
No. Validate the exact caption artifact and perform editorial and accessibility review before publication.