An artifact name is only one part of release identity
A deployment should consume the build artifact that passed the intended checks. An artifact named production-build can exist in many runs, so the name alone cannot identify which commit was tested. A traceable promotion ties the artifact to its producing run, commit, digest and acceptance evidence.
Rebuilding during deployment can create a different output even when the source revision matches. When the delivery model promises promotion of a tested artifact, retain and verify that artifact rather than silently replacing it with a new build from floating dependencies or a different environment.
Setup: define the promotion record
Record the repository, source commit, workflow identity, run ID, artifact name or ID and digest. Include build-tool and dependency-lock inputs needed to explain reproducibility. Define the retention period against the time the business needs to promote or recover that release.
Review the action versions supported by GitHub.com or the GitHub Enterprise Server deployment in use. Artifact behavior and supported action releases can differ across platforms. Keep the authentication used to download another run's artifact scoped to the required repository and operation.
Trace the artifact handoff
- Capture the artifact identity and digest from the successful producing run. Associate test results with that run and source commit, not merely a branch name that can move later.
- Download from the explicit intended run and verify the selected artifact. Check retention or deletion state before treating an unavailable artifact as a build failure.
- Inspect digest verification behavior. Current GitHub documentation describes a warning when automatic download verification finds a mismatch; a release policy that requires a hard stop must enforce its own failure condition.
- Validate the archive structure and expected files before extraction or deployment. Untrusted artifact contents remain input requiring checks even when transport integrity matches a digest.
Illustrative incident: deployment downloads the latest similarly named artifact
In this illustrative scenario, an approved release references a tested commit, but its download step selects the most recent artifact with a common name. Another workflow has completed in the meantime, so the deployment consumes a different build while the release record still points to the older test evidence.
The team pins the producing run and artifact identity and verifies the digest before promotion. It checks the serving commit after deployment. This example explains release traceability and does not claim a real customer release mismatch.
Diagnostic table
| Observation | Evidence | Boundary |
|---|---|---|
| Deployed output differs from tests | Run, commit and artifact IDs | Wrong producer selection |
| Artifact is unavailable later | Retention and deletion history | Release recovery availability |
| Verification emits a warning | Expected and observed digest | Integrity acceptance |
| Archive has unexpected paths | Manifest and extraction checks | Artifact content trust |
Verification and recovery acceptance
Exercise a release and a rollback using retained artifacts in a test environment. Confirm that both select explicit identities and pass the same integrity checks. Verify that the target reports the expected application revision after activation.
Keep database compatibility and runtime configuration separate from artifact identity. A matching application artifact does not reverse a destructive schema change or restore missing secrets. The release record should identify these additional dependencies and the owner of any recovery operation.
SOP and monitoring
Document producer workflow, artifact retention, digest verification policy, promotion authorization and deployed identity checks. Alert when required release artifacts approach expiry or are unavailable for a planned recovery exercise. The SOP should make it possible to explain exactly which tested bytes reached each environment, using stable run evidence rather than a moving branch or friendly artifact name.
See Clouvenix devops automation for implementation and operational handover.
Technical reference
Official reference 1. Documentation checked 20 October 2026; confirm behavior for your deployed edition and version.