Runner names are useful labels, not unique keys
A museum production team may run caption accessibility checks on GitHub-hosted and self-hosted runners. Someone reviewing the audit report sees `RUNNER_NAME=Hosted Agent` or a familiar machine label and assumes it proves which computer performed the check. GitHub’s variable and context references explicitly warn that runner names may not be unique in a workflow run; repository- and organization-level runners can share a name. Even a distinct-looking label can be renamed or reused. The audit question is therefore not “What friendly name appeared?” but “Which workflow job and attempt produced which exact test output under which trust conditions?” The diagrams in this guide use invented runner names.
Capture an execution record with separate identities
At job start, record `RUNNER_NAME`, `RUNNER_OS`, `RUNNER_ARCH`, and `RUNNER_ENVIRONMENT` for context, together with the actual repository ID, workflow run ID, run attempt, job identifier, and tested commit SHA. These fields answer different questions and none should be collapsed into the runner label. GitHub also exposes the `runner` context, including `runner.name`, which is useful for expressions. Do not assume a runner’s human-readable label is the same as its service registration ID or an immutable hardware fingerprint. Keep timestamps and the workflow-file revision so a later reviewer can reconstruct when, what, and how the check ran.
Separate GitHub-hosted and self-hosted trust assumptions
`RUNNER_ENVIRONMENT` distinguishes GitHub-hosted from self-hosted execution environments, but it is not a certificate that the workload was isolated correctly. A self-hosted machine may preserve state between jobs or expose local credentials if incorrectly configured. A GitHub-hosted runner has different lifecycle assumptions and available tooling. In either case, pin trusted action dependencies, give the job the minimum token permissions, and avoid executing untrusted pull-request content with privileged credentials. The runner label must never serve as an authorization allowlist by itself. If a release gate depends on a protected environment, validate the configured environment and protection rules directly.
Do not confuse name repetition with a duplicated job
Two legitimate jobs can report exactly the same runner name. Conversely, one logical workflow may use different runner labels on separate attempts. To identify a duplicated execution, compare run IDs, attempts, job IDs, and the actual test artifacts; a string match on `RUNNER_NAME` is insufficient. A conceptual diagram can show two identical name badges attached to different job cards, followed by separate validated reports. That does not represent a real GitHub run or a measured concurrency condition. If a caption checker writes to a shared destination, generate artifact names with run and attempt identifiers rather than using the runner label as a filesystem key.
Keep artifact evidence connected to checked content
A caption QA report needs the subtitle or transcript file paths, their content hashes where appropriate, the validator version or digest, the tested commit, and the resulting diagnostics. Record whether the file was generated, manually edited, or taken from an approved collection master. The name of the runner adds context but cannot prove the captions are accurate. If the job checks a PR merge commit, keep that exact tested SHA separate from the source branch’s head SHA. A green summary from an unrelated run or a report using different caption files should not satisfy the release gate. Human accessibility review remains independently necessary.
Protect logs and avoid sensitive machine details
Runner names can accidentally reveal internal hostnames, staff initials, project labels, or server topology. In public workflow logs and downloadable artifacts, decide whether the full label is necessary; a restricted audit log can preserve it while the public-facing report uses a safer identifier. Never print environment secrets, local credential paths, personal data, or raw output from an untrusted contribution merely to establish provenance. For a self-hosted runner, restrict who can view diagnostic bundles and inspect whether reusable workspaces contain credentials or stale files. Do not treat an unfiltered debug log as safer evidence simply because it contains more information.
Use the runner context carefully in workflows
In a workflow YAML expression, `runner.name` provides the available runner name. Inside a shell step the related default environment variable is `RUNNER_NAME`. GitHub documents that default `GITHUB_*` and `RUNNER_*` environment variables cannot normally be overwritten by user workflow commands. Read them rather than trying to relabel a runner to pass a conditional check. When writing a summary artifact, quote values and serialize as data rather than interpolating untrusted text into shell commands. The safest audit mapping is explicit structured fields, not a hand-built command line assembled from a display name.
Check reruns and changed operating environments
When a job is rerun, it may execute on a different runner or machine image even if its human-readable name looks the same. Compare run attempt, workflow file revision, source SHA, operating system, architecture, and tool versions before treating results as equivalent. A previously cached binary or a changed runtime dependency can produce different behavior without any change in the caption source. If a failure disappears on rerun, keep both result artifacts instead of overwriting the first. Do not invent a root cause from the machine label. Investigate the actual stderr, test setup, package digests, and permission scopes.
Approve the result, not the label
Before publishing captioned material, confirm that the intended workflow ran with reviewed dependencies, the checked commit matches the release, required tests passed, and accessibility or editorial approvers have signed off. `RUNNER_NAME` is one provenance field within that record, not proof of CI integrity. Consult current GitHub runner and security documentation when designing self-hosted access because runner features and recommended hardening can change. The example cards and paths in this article are synthetic training illustrations; no GitHub repository or CI service was accessed. A defensible record makes individual runs reproducible without claiming a runner’s friendly name provides globally unique identity.
How We Research
Primary official technical sources reviewed November 11, 2026: GitHub Actions variables reference; GitHub Actions contexts reference; GitHub security: secure use reference. We checked GitHub Actions default variable and runner context references and security guidance, then designed a hypothetical caption QA audit across different workflow jobs. No repository, runner, workflow output, or release record was inspected. All example identifiers, diagrams, comparisons, and quantities here are instructional constructs, not empirical test results, vendor screenshots, or production traces. Verify current API versions, access permissions, model support, prices, security requirements, and local policy before implementing with real data.
Frequently Asked Questions
No. GitHub warns that the name can be reused by repository- and organization-level runners.
No. Add run, attempt, job, source revision, and optionally a content hash to avoid collisions.
No. It describes hosted versus self-hosted execution; security depends on actual isolation, permissions, dependencies, and controls.
The rerun may use a different runner or a repeated display label. Record each attempt separately.
No. Inspect the real validation report and maintain independent human accessibility approval.