Context
Re-running a failed workflow sounds like repeating the same operation. The source commit may be the same, but dependency tags, base images, downloaded scripts, secrets, and external services can change between attempts. A reliable release record therefore needs more than a commit SHA. It must identify the inputs and artifact that the team actually tested and promoted.
Understand the documented re-run identity
GitHub documents that re-runs use the original event's GITHUB_SHA and GITHUB_REF, and the privileges of the actor who initially triggered the workflow. That establishes important context, but it does not freeze every external input a job resolves. Review the current re-run documentation and the workflow's own checkout and download steps.
Inspect scripts that explicitly check out a branch or fetch another repository. They may override the intended original source context. A log displaying the original workflow SHA does not prove that every build step used that source tree. Record the actual checked-out revisions where multiple repositories or custom scripts are involved.
An illustrative changed artifact
Imagine a release build that succeeds, then fails while publishing documentation. The next day, an engineer reruns the entire workflow. A floating base-image tag now resolves differently, producing another application image under the same release version.
Compare the original and rerun artifact digests. If they differ, treat them as separate candidates even when the application source commit matches. Decide whether to continue the verified original artifact or create and test a new candidate. Do not call the second build identical merely because it came from the same commit.
Inventory mutable inputs
List package resolution, lockfiles, base images, action references, toolchain versions, downloaded binaries, remote configuration, and build-time secrets that can affect output. Some inputs should be pinned, while others need an explicit change record.
Review reusable workflows and helper repositories as well as the main workflow file. A top-level pinned action does not establish the identity of a script it downloads later. Use checksums, immutable revisions, or trusted artifact mechanisms appropriate to each input.
Separate retry from rebuild
When a job fails after producing an artifact, prefer a continuation path that consumes the retained candidate when the release design supports it. Rebuilding should be an explicit operation with a new artifact identity, even if the same source is used.
Keep build, test, approval, and deployment evidence connected to the candidate digest. A deployment approval based on one artifact should not silently apply to different bytes created by a rerun. If the artifact has expired, resolve that gap through a documented release decision instead of inventing continuity.
Review privileges and environment gates
The documented original-actor privilege behaviour matters when another person initiates a rerun. Check the workflow event, token permissions, environment protection, and cloud trust conditions in the actual job. Do not infer the effective access from the name of the person clicking Re-run.
Revalidate time-sensitive release gates where required by the organisation's process. An old successful test may no longer represent a changed external dependency or production state. State which evidence is retained and which checks rerun during continuation so reviewers can assess the actual candidate.
Handle partial external effects
A failed workflow may already have created a release, pushed an image, updated a server, or run a migration. Design those steps with stable operation identifiers and desired-state checks. A rerun must recognise completed work and uncertain outcomes.
Before repeating a deployment step, inspect the current runtime release and deployment receipt. If the earlier command lost its response after success, blindly running it again can create avoidable disruption. Resolve the observed state first, then continue from the appropriate boundary.
Test the failure path intentionally
Force a controlled failure immediately after artifact upload, registry push, and deployment acknowledgement in a test environment. Rerun the selected jobs and confirm each resumes according to the intended contract.
Include a changed floating input in a demonstration test. This makes the difference between source identity and artifact identity visible to the team. The test should prove that the pipeline either retains the original candidate or clearly reports the new artifact and requires its relevant validation.
Quick diagnostic map
| Evidence | Interpretation | Next check |
|---|---|---|
| Same SHA; different artifact | Mutable input changed | Compare candidate digests |
| Rerun repeats deployment | External outcome unresolved | Read target receipt |
| Approval refers to old bytes | Candidate identity changed | Revalidate promoted artifact |
A focused operator exercise
Select a synthetic release and record the checked-out source revisions, action references, toolchain, dependencies, base-image digest, artifact digest, and workflow attempt. Fail the job immediately after publishing the candidate. Resume through the intended rerun path and confirm it either consumes that same candidate or clearly identifies a newly built artifact for fresh validation.
Change one floating test input between attempts and compare output identity. The pipeline should expose the difference rather than reporting equivalence solely from GITHUB_SHA. Inspect helper scripts that fetch branches or remote assets and verify their actual revisions appear in the receipt. Keep original-actor privileges and environment gates visible during the exercise.
Then simulate a lost deployment acknowledgement and query the target before repeating mutation. Confirm the current runtime release can be reconciled to the retained artifact and attempt. The exercise passes when the team can explain source identity, build inputs, candidate identity, approval, and external effects independently, with no ambiguous “rerun passed” record substituting for deployment evidence.
Make the receipt explain the attempt
Record workflow run, attempt, source revisions, input versions, artifact digests, tests, approval, and observed runtime release. Keep one clear candidate identity across those records. Avoid reporting “rerun passed” without naming what was built and deployed.
Clouvenix can help restructure release continuation so reruns remain reviewable. The outcome is a pipeline that can recover from partial failure without losing the connection between source, tested artifact, and production bytes.
Frequently asked questions
Does the same commit guarantee a reproducible build?
No. Reproducibility also depends on toolchains, dependencies, base images, scripts, and relevant build inputs. Capture and control those inputs, then compare artifact identity rather than inferring equality from the commit alone.
Is rerunning only a failed deployment job always safe?
Only if its retained artifact, credentials, approvals, and current external state still satisfy the release contract. Check for partial deployment and durable side effects before repeating the action.
Explore Clouvenix devops automation for implementation and operational handover.