CI/CD Fundamentals · Module 06 of 12

Artifacts, outputs and release evidence

Move data deliberately between jobs, preserve build outputs and separate tiny job outputs from file artifacts.

Learning objectives

By the end of this module, you should be able to:

Distinguish step/job outputs from file artifacts.
Package immutable release evidence once and reuse it downstream.
Verify artifact integrity before promotion.

Outputs are small values

Job outputs are useful for identifiers, booleans or computed metadata that downstream jobs need. They are not a substitute for transferring a compiled application or large report.

Artifacts carry files across job boundaries

Artifact upload/download actions persist files from one job so another job or a human can retrieve them. Build once and promote the same artifact instead of rebuilding separately for each environment.

Integrity checks strengthen promotion

A checksum provides evidence that the bytes being promoted are the bytes that were validated. More advanced supply-chain controls can add provenance and attestations.

Worked examples

See the idea in practice.

Artifact handoff

- uses: actions/upload-artifact@v7
  with:
    name: application
    path: dist/
# downstream job
- uses: actions/download-artifact@v8
  with:
    name: application

The artifact is the explicit cross-job file handoff.
Use an immutable source/build identity in metadata where possible.

Hands-on lab

Lab — Build once, verify and promote the same artifact

Goal: Create an artifact plus checksum and verify it before copying into a simulated staging release.

STEP 1

Build artifact

mkdir -p ~/gnu-cicd-labs/module06/{build,staging} && cd ~/gnu-cicd-labs/module06
printf 'release-content\n' > build/app.txt
tar -czf application.tgz -C build app.txt

STEP 2

Record integrity

sha256sum application.tgz > application.tgz.sha256

STEP 3

Verify before promotion

sha256sum -c application.tgz.sha256

STEP 4

Promote exact bytes

cp application.tgz application.tgz.sha256 staging/
sha256sum -c staging/application.tgz.sha256 --ignore-missing

Verify

The checksum validates before and after promotion.
The staging copy is byte-identical to the validated artifact.

Expected outcome

One artifact is built and then promoted rather than rebuilt.

If it fails

A checksum mismatch means the bytes changed; do not deploy until the discrepancy is understood.
Ensure the checksum file references the expected filename in the verification directory.

Real-world connection

Promoting one immutable artifact prevents environment-specific rebuild drift.

Avoid these traps

Common mistakes

Rebuilding for production after validating a different staging build.
Using job outputs to move large binaries.
Ignoring integrity mismatches during promotion.

Knowledge check

Can you explain it without looking back?

Open each answer only after you have tried to answer the question yourself.

1When should you use an artifact rather than a job output?

When you need to transfer files such as binaries, packages or reports between jobs or retain them after the run.

2Why build once and promote?

It keeps the deployed bytes identical to the bytes that passed validation.

3What does a checksum help prove?

That the artifact bytes have not changed between validation and promotion.

My Learning

Record your progress for this module.

Progress is saved in this browser immediately. When you sign in to My Learning, it can also sync across devices.

Not started

Core lab attemptedRecord this after meaningfully completing or attempting the module's core lab.Knowledge checks attemptedThis is marked automatically after you open every answer in the module; you can also record it manually.

Attempt the core lab and knowledge checks before marking the module complete.