1.2.2. Jobs, Steps, and the Runner Contract
💡 First Principle: A runner is a disposable worker that accepts one job, executes its steps in order on a clean machine, reports results, and is thrown away. That disposability is a feature — it's what makes runs reproducible — and it dictates how all data flows in Actions.
The contract works like a hotel room, not an apartment: everything you need, you bring with you or request explicitly, because the room is reset between guests. That's why nearly every job starts with actions/checkout (your own code isn't even there until you fetch it!) and a setup-* step for toolchains. It's also why the platform provides explicit mechanisms — artifacts, caches, outputs — for anything that must outlive the job.
Within a job, steps share the runner's filesystem and environment, run sequentially, and stop by default at the first failure (a step failing means a nonzero exit code). Between jobs, there is no sharing — only ordering, declared with needs:, plus the deliberate data channels covered in Phase 2.3. Runners come in two big families you'll compare properly in Phase 3: GitHub-hosted (managed, ephemeral by design) and self-hosted (your machines, your rules, your risks).
⚠️ Exam Trap: "The build job installed the CLI, so the deploy job can use it." No — deploy starts on a fresh VM. Persisting a tool means reinstalling it, caching it, or containerizing it. If an answer option assumes state survives across jobs, it's wrong.
Reflection Question: Reproducibility and speed pull in opposite directions here: fresh VMs guarantee clean state but force reinstallation. Which mechanisms (coming in 2.3) let you buy speed back without giving up the clean-state guarantee?
