GitHub Actions GITHUB_RUN_ATTEMPT: Keep Re-run Caption Reports Separate

How a re-run can erase useful evidence

A museum accessibility team uses GitHub Actions to check subtitle timing and caption formatting before a kiosk release. The first workflow attempt reports a problem. An operator reruns the same workflow after investigating a flaky tool, and the second report is saved under exactly the same local filename. When the team later reviews the release, it cannot easily distinguish the original failed evidence from the second result. GitHub provides `GITHUB_RUN_ATTEMPT` specifically to distinguish attempts for a given workflow run. Using that value in evidence naming helps preserve provenance, but it does not by itself approve a release or guarantee that test outputs cannot be overwritten.

Understand run IDs, run numbers, and attempts

GitHub documents `GITHUB_RUN_ID` as a unique identifier for one workflow run within a repository, and it remains unchanged when that run is rerun. `GITHUB_RUN_ATTEMPT` starts at 1 and increments each time the run is rerun. The workflow’s `GITHUB_RUN_NUMBER` also stays unchanged on rerun; it increments for a new run of that workflow. Those are three different identifiers. A defensible evidence key should combine repository, run ID, attempt, and an artifact purpose, rather than rely on a timestamp or branch name alone. Branch names are user-controlled in many pull-request contexts and should never become unsanitized path components.

Choose a provenance-friendly artifact name

A conceptual filename might be `caption-audit-run-12345-attempt-2.json`, built from environment variables after numeric validation. In a real repository, use the GitHub-provided ID and attempt values rather than hardcoded sample numbers. Store a stable report schema version alongside the test tool version, commit SHA, and configuration digest so two reports can be interpreted against the same rules. A unique name reduces accidental collisions within a run, but it is not immutable storage. Review upload-artifact action version, retention policy, and any overwrite options before claiming preservation. The goal is that a reviewer can always identify which attempt produced a given file.

Conceptual process steps for GitHub Actions GITHUB_RUN_ATTEMPT: Record run ID; Read attempt number; Name evidence uniquely; Compare review reports.

Use step variables in the correct execution context

`GITHUB_RUN_ATTEMPT` and `GITHUB_RUN_ID` are default environment variables set in the runner context. They can be read by a shell step, while workflow expression logic may use corresponding `github` context fields. Do not try to overwrite a `GITHUB_*` variable; GitHub documents these defaults as protected from redefinition. For reproducible reporting, validate that expected variables are present, sanitize every string you place in an artifact path, and avoid evaluating untrusted pull-request content as shell commands. If a local developer runs the checker outside GitHub Actions, provide an explicit local mode rather than pretending the environment variables exist.

Separate re-run attempts from independent new runs

A re-run of run ID A with attempt 2 is not the same event as an entirely new workflow run ID B at attempt 1, even if both target the same commit. Review the event type, commit SHA, workflow definition, and input configuration for each report. A new run might include different code or different repository settings; an attempt number alone does not show this. Keep a small evidence ledger with the run link, attempt, artifact name, and CI result. This structure lets reviewers answer whether a failure was intermittent or whether a correction was actually committed between runs. Never infer that a second attempt contains a fix merely because the result changed.

Prevent evidence overwrite and retention surprises

Check whether the chosen artifact action treats a name as unique per workflow run, whether overwrite is enabled, and what happens when an upload is retried. Prefix or suffix filenames with the attempt so an operator does not confuse two reports downloaded into the same local folder. If the retention period is shorter than the organization’s audit period, export approved summaries into managed evidence storage under a separate retention policy. GitHub’s default retention value and repository policies can change; inspect your actual settings instead of stating a universal duration. Do not assume Actions logs are permanent records or that preserving reports means preserving sensitive caption source files is allowed.

Illustrated comparison of three different states for GitHub Actions GITHUB_RUN_ATTEMPT: ATTEMPT 1; ATTEMPT 2; EVIDENCE LEDGER; no measured test results.

Compare reports without changing the approval rule

An accessibility reviewer should compare attempt 1 and attempt 2 along with the exact configuration under which each was produced. Highlight the original failed caption rule, any changed tool version, and the rerun’s result without inventing an accuracy percentage. If an issue disappears on rerun without a source change, record it as unresolved flakiness until investigated. A passing report is a data point, not a substitute for the museum’s sign-off policy. Keep the protected branch and required-review controls intact so reruns cannot silently bypass the normal approval process.

Consider the actor behind a re-run

`GITHUB_RUN_ATTEMPT` identifies which execution you are looking at, not who had authority to initiate or approve it. The re-run initiator may differ from the original workflow actor; GitHub documents separate identity fields for that reason. Workflow re-runs use the original actor’s privileges, so a re-run button press does not grant the clicker new workflow permissions. Include actor review in a privileged release investigation, but keep identities and permissions distinct from evidence file naming. Avoid treating a user name from an event payload as a safe shell token or as evidence of policy authorization.

Illustrated audit checkpoints for GitHub Actions GITHUB_RUN_ATTEMPT: Run ID kept stable; Attempt tagged on files; Reviewer gate unchanged.

Make the release report independently reviewable

At the release gate, assemble a small table or summary that links each inspected attempt to a particular artifact, commit, tool version, reviewer conclusion, and approved release ticket. A link should lead to a real run or internal evidence copy, not a fabricated report. If an attempt’s artifact is missing, label the evidence gap instead of silently using a later result. Retain only the required data for the authorized period, especially where caption files contain speaker names or personal information. The final kiosk publish decision should remain an explicit human or controlled policy action, separate from the automatically generated CI status.

How We Research

We reviewed GitHub’s Actions variables reference, the workflow artifact guide, and workflow syntax reference. The documentation distinguishes run IDs, attempts, and default environment variables. The caption QA example is hypothetical; no repository, CI job, artifact, or approval history was accessed.

Frequently Asked Questions

Does GITHUB_RUN_ID change when I rerun a workflow?

No. The run ID stays the same; GITHUB_RUN_ATTEMPT increases for the rerun.

Does GITHUB_RUN_NUMBER count reruns?

No. It identifies new runs of the workflow and remains unchanged on a rerun.

Is an attempt-specific artifact name enough to guarantee retention?

No. Artifact action behavior, overwrite settings, and repository retention still matter.

Can a re-run passing result replace the original failure in an audit?

Do not erase the original evidence. Compare attempts and document unresolved differences.

Does a higher attempt number mean a reviewer approved the change?

No. Attempt metadata describes execution, not authorization or sign-off.

Scroll to Top