Trace the file before the upload
An engineering manager wants the test report behind a green badge but cannot find it. Confirm the report command wrote the expected file on that run, then inspect the upload step and its configured path. A successful test does not necessarily create a report, and a created report does not prove an upload retained it. Do not fabricate a report from a later run as evidence for an earlier revision.
- Keep repository, workflow, run ID, commit and artifact name together.
- Inspect redacted summaries rather than publishing customer records or secrets in reports.
Check naming, lifetime and version behaviour
Compare the requested artifact name with the uploaded one and check whether its retention expired. Configured retention cannot exceed the relevant repository or organisation limit. With v4, an artifact is immutable: a later job producing changed content should publish a distinct artifact rather than assume it can edit the first upload.
- Agree how long acceptance evidence must remain inspectable.
- Keep dependencies between producer and consumer jobs explicit.
Download the right evidence
A download from another workflow run needs the correct run ID and authorised access. Downloading all artifacts can create separate directories, so a consumer looking only at its current directory may miss the file. GitHub also documents digest validation: a mismatch creates a warning. Review that warning explicitly rather than assuming the download's success proves integrity or that a mismatch necessarily fails CI.
- Do not grant broad tokens merely to fetch one report.
- Inspect untrusted artifacts as data, not executable instructions.
Acceptance is a retrievable report
For the agreed run, retrieve the named report and show that it covers the expected tests and revision. Keep its digest and any validation warning in the handover, along with retention limits. This establishes evidence availability, not customer acceptance or production release. A repair enquiry can use redacted run and artifact details; private access and any recurring evidence-retention responsibility require a scoped proposal.
Sources and limits
- GitHub: storing workflow data as artifacts Checked 2026-10-10.
- Artifacts have names and retention periods subject to repository, organisation or enterprise limits.
- With v4 uploads, artifacts are immutable; changed outputs use a new artifact.
- Downloading from another run requires its run identifier and an appropriate token.
- Digest mismatch during download produces a warning, not documented proof that a job must fail.