Container Builds and Registry Push — CI/CD with GitHub Actions

Containers have become the universal packaging format for modern applications. A Docker image encapsulates an application with all its runtime dependencies — OS libraries, language runtimes, configuration — into a self-contained, reproducible unit that runs identically on a developer's laptop, in a CI runner, and in a production Kubernetes cluster. Building container images in CI and pushing them to a registry is the production-ready evolution of the artifact pattern from the previous lesson: instead of a zip file that only works on the same OS and architecture it was built on, a container image works everywhere Docker or a container runtime is available. In GitHub Actions, the `docker/build-push-action` combined with the GitHub Container Registry (`ghcr.io`) provides a zero-additional-cost container build and storage pipeline that integrates natively with repository permissions and GitHub's authentication model.

Analogy🏏Cricket

🏏 Think of it like cricket: A cricket series is structured in three tiers: the series schedule (which matches are played and when), individual match plans (batting order, bowling rotations, fielding strategy), and specific delivery plans (which balls to bowl to which batsman in which over). The series schedule is the workflow — it defines the overall event. Each match is a job — it runs independently but contributes to the series outcome. Each delivery plan is a step — a specific action with a discrete result. Just as a Test captain doesn't redesign the series schedule for every match but does adjust the bowling plan for each innings, GitHub Actions separates what triggers the automation (workflow) from how independent tasks are parallelised (jobs) from the individual commands executed (steps). The insight is that this separation of concerns is what allows large, complex pipelines to remain manageable — just as a well-structured series plan keeps a touring team organised across multiple venues and formats.