Building and Compiling in CI — CI/CD with GitHub Actions

The build stage is the first substantive transformation in a CI pipeline: it takes raw source code and produces a deployable artifact. Without a reliable, reproducible build in CI, every developer's machine becomes the canonical build environment — a fragile situation where 'it compiles on my laptop' is the only guarantee. CI builds solve this by executing in a clean, controlled environment on every commit, verifying that the code is not just syntactically valid but actually compilable with its declared dependencies. For interpreted languages like JavaScript or Python, the build step installs dependencies and may bundle or transpile code. For compiled languages like Go, Java, or Rust, it produces a binary. Either way, the CI build stage is the authoritative source of truth for whether the codebase is in a buildable state.

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.