Artifacts and Workflow Outputs — CI/CD with GitHub Actions

Pipelines produce outputs: compiled binaries, test reports, coverage files, build manifests, security scan results, generated documentation. Without a mechanism to persist these outputs and share them across jobs, every downstream job that needs them must regenerate them — wasting time and risking inconsistency. GitHub Actions provides two distinct mechanisms for this. Artifacts are files uploaded to GitHub's storage during a workflow run, downloadable from the run UI or via the API, and accessible to downstream jobs. Job outputs are small string values exposed from one job's steps and readable by any dependent job via `needs.job.outputs.value`. Understanding when to use each — artifacts for binary files and large data, outputs for small string values like version numbers or file paths — determines whether pipelines are efficient and maintainable or redundantly rebuilding the same outputs repeatedly.

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.