CI/CD
Intermediate 15 min read CI/CD

Building & Artifacts

Build tools compile source into reproducible artifacts that are versioned, checksummed and stored in registries. Learn reproducible builds, artifact versioning, container registries and integrity verification so production runs exactly what you built.

buildartifactreproducible buildversioningsemverregistryDocker HubECRGHCRchecksumsigning
Prerequisites: CI/CD Fundamentals Designing Pipelines
Introduction

What is this?

A build takes source code and turns it into a deployable artifact — a compiled binary, a bundled package or a container image. Reproducible builds produce identical artifacts from identical input. Artifacts are versioned (semantic versions or commit SHAs), verified with checksums and signatures, and stored in registries such as Docker Hub, Amazon ECR or GitHub Container Registry.

Motivation

Why do you need it?

  • Reproducibility means any build, from any machine, at any time, produces the same artifact from the same source.
  • Versioning artifacts makes every deployment traceable to the exact code that produced it.
  • Checksums and signatures detect corrupted or tampered artifacts before they are deployed.
  • Registries give teams one place to store, scan, promote and retrieve immutable artifacts.
  • An immutable artifact is the backbone of safe rollbacks — you redeploy the old version, not rebuild it.
Think about it

Mental model

Imagine

A bakery stamping each loaf with a batch number

Think of

Versioned, signed artifacts

Every loaf (artifact) carries a batch number (version) and is inspected before leaving (checksum). If one batch is bad, you recall exactly that batch and re-bake from the same recipe (source) — you never sell a loaf you did not bake (reproducibility).

Mechanics

How it works

  • The build tool resolves dependencies, then compiles or bundles source into a deployable output.
  • Build steps are pinned to exact tool and dependency versions so results do not drift over time.
  • The artifact is stamped with an identifier — a semantic version, commit SHA or build number.
  • A checksum (SHA-256) and optional signature are computed and stored alongside the artifact.
  • The artifact is pushed to a registry with the version as its tag, and environments promote that same immutable artifact.

From source through build to a versioned artifact in a registry.

Source
Build tool
Artifact
Verify
Registry
Reference

Key commands

docker build -t myapp:1.4.0 .

Produce an image artifact with an explicit version tag.

docker tag myapp:1.4.0 ghcr.io/acme/myapp:1.4.0

Retag the image for a specific registry repository.

docker push ghcr.io/acme/myapp:1.4.0

Upload the artifact to the container registry.

docker image inspect myapp:1.4.0 --format '{{.Digest}}'

Show the content-addressed digest of the image.

git tag v1.4.0

Mark the source revision that produced the artifact.

Hands-on

Examples

Build and push a versioned, checksummed container image

Build and push a versioned, checksummed container image
VERSION=1.4.0
docker build -t myapp:$VERSION .
docker tag myapp:$VERSION ghcr.io/acme/myapp:$VERSION
sha256sum image.tar > image.tar.sha256
docker push ghcr.io/acme/myapp:$VERSION
# verify integrity after pull
docker pull ghcr.io/acme/myapp:$VERSION
docker image inspect ghcr.io/acme/myapp:$VERSION --format '{{.Digest}}'

The image is built, tagged with a semantic version, and pushed to a registry. The tag points to a digest (content hash), so consumers can pin by digest to guarantee they run exactly the verified artifact.

Real world

In production

  • Images are pushed with both a semver tag and the commit SHA so teams can pin deployments to a verified digest.
  • Registries with built-in scanning (GHCR, ECR) gate deployments on vulnerability results.
  • CI signs images with cosign or Notary so production only accepts signatures from the trusted pipeline.
  • Build caches keyed by lockfile hash keep rebuilds fast without sacrificing reproducibility.
  • SBOMs generated at build time feed vulnerability management and license compliance.
Guidelines

Best practices

  • Pin base images and dependency versions; never build from unpinned latest.
  • Tag artifacts with semver plus commit SHA, and treat tags as immutable once released.
  • Compute a SHA-256 checksum and signature for every artifact before storage.
  • Use digest-pinned references in production so a mutable tag can never change what runs.
  • Scan images and dependencies in the build stage, before they reach a registry.
Watch out

Common mistakes

  • Reusing the latest tag for every push, destroying the ability to roll back to an exact artifact.
  • Building with unpinned dependencies and getting different binaries days later.
  • Ignoring checksums and pulling artifacts over unverified channels.
  • Storing build artifacts only on the runner's ephemeral disk where they are lost between runs.
Root cause analysis

Common issues

Error
image not found / manifest unknown in registry
Root cause

The tag was never pushed, was deleted, or was overwritten with a different digest.

Fix

Re-push the artifact with the exact tag and confirm with docker image inspect before deploying.

Error
Build succeeds locally but the registry refuses the push
Root cause

Authentication failed or the repository name does not match the registry account.

Fix

Run docker login to the registry and confirm the repository is owned by the authenticated account.

Error
Checksum mismatch after pulling an artifact
Root cause

The artifact was corrupted in transit or tampered with at rest.

Fix

Re-pull, re-verify against the signed checksum, and if it persists, rebuild from source — never deploy a mismatching artifact.

When things break

Debugging tips

  • Compare image digests of a passing and failing deployment to see if the wrong artifact ran.
  • Rebuild from the exact pinned commit and lockfile to prove a flaky build is environmental.
  • Check layer caching: a changed cache key silently rebuilds everything and can hide failures.
  • Verify registry push by pulling a fresh copy and comparing digests locally.
Interviews

Interview checkpoint

Practice

Hands-on lab

Build, Version and Verify a Container Artifact
30 min · intermediate
In progress
Objectives
  • Create a build definition for a container image
  • Build and tag an artifact with a version
  • Retag the artifact for a registry repository
  • Verify the artifact by digest

Build, Version and Verify a Container Artifact

30 min · intermediate

0/6 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/3
1

Why is an immutable artifact important for rollbacks?

2

Using the latest tag for releases is a reliable way to know what is deployed.

3

Which of these best verifies an artifact's integrity after a pull?

Quick reference

Cheat sheet

Versioning
v1.4.0Semantic version for a release
sha-<40 hex>Commit SHA for traceability
<semver>-<sha>Combined tag convention
git tag v1.4.0Mark the producing revision
Integrity
sha256sum fileCompute a checksum
docker image inspect --format '{{.Digest}}'Show image digest
docker pull <image>@<digest>Pull an exact image
cosign sign <image>Sign an artifact
docker buildxMulti-platform, cached builds
Go deeper

Official documentation

Docker build documentation
docs
GitHub Container Registry
docs
Amazon ECR User Guide
docs
Semantic Versioning 2.0.0
spec