1.2.1. Events and Triggers: The Nervous System
💡 First Principle: Nothing in GitHub Actions runs unless an event fires — workflows are pure reactions. Controlling automation therefore means controlling which events you listen to, and how narrowly.
Events come in a few families, and knowing the family tells you most of what the exam wants:
| Event family | Examples | Typical use |
|---|---|---|
| Repository activity | push, pull_request, issues, release | CI, PR checks, triage |
| Scheduled | schedule: with cron (UTC) | Nightly builds, stale-issue sweeps |
| Manual | workflow_dispatch | On-demand deploys with inputs |
| Workflow-to-workflow | workflow_call, workflow_run | Reusable pipelines, chaining |
| External | repository_dispatch | Systems outside GitHub kicking off runs |
Two refinements matter constantly. First, most repository events have activity types (opened, closed, labeled…) so you react to the specific state change, not the whole category. Second, filters (branches:, paths:, tags:) narrow which pushes or PRs count. A workflow that runs on every push to every branch is usually a beginner's cost problem; one that runs on the wrong event with elevated permissions is a security problem (Phase 6).
⚠️ Exam Trap: schedule: cron expressions are evaluated in UTC, may be delayed or skipped under load, and only run from the default branch. If a question mentions a scheduled workflow "not firing at the expected local time" or "not running on my feature branch," those are the answers.
Reflection Question: Why would GitHub design scheduled workflows to run only from the default branch — what could go wrong if any branch's copy of a scheduled workflow fired?
