5.1. GitHub Actions for Automation
Every meaningful change to a repository is an opportunity to run something automatically — tests, builds, deployments — and GitHub Actions is the engine that makes that automatic.
💡 First Principle: GitHub Actions runs workflows — automated sequences of steps — in response to events in a repository, such as a push, a pull request, or a schedule. A workflow is defined in a YAML file stored in the repository itself (.github/workflows/), so the automation lives and versions alongside the code it acts on, rather than being configured separately in some external tool.
Each job in a workflow executes on a runner — a virtual machine (GitHub-hosted or self-hosted) that provisions fresh for that run. Because workflows are triggered by repository events, the same push that satisfies the GitHub Flow's review process can also kick off tests, a build, and a deployment, all without a person manually starting any of them.
⚠️ Exam Trap: A GitHub Actions workflow file lives inside the repository it automates (under .github/workflows/) — it is version-controlled, reviewable in a pull request, and branch-specific, not a separate global configuration.
Reflection Question: A team wants tests to run automatically on every pull request, before anyone reviews it. What repository event should the workflow be configured to trigger on?
