Events, Triggers and Contexts — CI/CD with GitHub Actions

A workflow that runs at the wrong time — or doesn't run at all — is useless automation. GitHub Actions provides a rich event system that lets you precisely control when workflows execute: on every push to any branch, only on pull requests targeting the main branch, on a cron schedule, when another workflow completes, or even manually via the GitHub UI. Beyond simply firing, events carry a context — a structured object containing metadata about the event, the repository, the actor who triggered it, and the runtime environment. Understanding how to read context values and use them in workflow expressions is what separates static, hard-coded pipelines from dynamic, self-aware automation that can adapt its behaviour based on which branch is being built, who pushed the code, or what the current run number is.

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.