GitHub Actions

Story

Building-a-house world — same site and crew as every Phase 0 lesson.

Picture the moment you drop your finished work at the approval desk (that was lesson 0.4 — a pull request). You walk away. You didn't press any buttons, you didn't call anyone.

But the moment that work lands on the desk, an automatic inspection rig springs to life on its own. It tests the wiring. It checks the wall is level. It sounds the smoke alarm. Then it hangs a green light (all good) or a red light (something failed) right on the PR for everyone to see.

Nobody pressed start. Nobody stood there watching. The rig runs the same routine every single time — every PR, every push, no exceptions.

That automatic inspection rig is GitHub Actions.

The idea

"GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your build, test, and deployment pipeline."

CI/CD = continuous integration / continuous delivery. Plain English: automatically test every change, and automatically ship it once it passes. Think: "every time someone drops work at the desk, run the same safety checks."

The vocabulary, top to bottom — verbatim definitions from the docs:

• Event — "a specific activity in a repository that triggers a workflow run." Examples: pull_request (someone opens a PR), push (a commit is pushed), an issue is opened, or a schedule fires.
• Workflow — "a configurable automated process that will run one or more jobs." Defined in a YAML file inside the .github/workflows/ directory. (Lesson 0.7 covers the YAML syntax.)
• Job — "a set of steps in a workflow that is executed on the same runner." Jobs can run in parallel.
• Runner — "a server that runs your workflows when they're triggered." Either GitHub-hosted (free, maintained by GitHub) or self-hosted (your own machine).
• Step — steps are "executed in order and are dependent on each other." Each step is either a shell script or a call to a reusable action.
• Action — "a pre-defined, reusable set of jobs or code that performs specific tasks within a workflow, reducing the amount of repetitive code you write."

source: docs.github.com — Understanding GitHub Actions · fetched 2026-05-28

The chain — a concrete trace

Abstract chains don't stick. Here's the full sequence you can follow step by step, using a real scenario: the robot worker (AI agent) opens a PR.

1. PR is opened
   └─ this is the EVENT  (pull_request)

2. GitHub sees a workflow file: .github/workflows/ci.yml
   that says "run when: pull_request"
   └─ the WORKFLOW is triggered

3. The workflow has one JOB called "test"
   └─ GitHub books a RUNNER (a fresh server) for that job

4. The runner works through the JOB's STEPS in order:
   Step 1 → check out the code  (reusable ACTION: actions/checkout)
   Step 2 → install dependencies  (shell script: npm install)
   Step 3 → run the test suite    (shell script: npm test)

5. All steps passed → JOB = ✓
   One step failed  → JOB = ✗

6. The result appears on the PR as a CHECK:
   green ✓ "test · passing"   or   red ✗ "test · failing"

Common uses: run tests on every PR, build the app, deploy on merge, lint the code, run security scans.

Why this matters for GH-600

Two reasons the exam cares:

1. Actions is where the checks on a PR come from. When an agent opens a PR, the pull_request event fires and triggers any matching workflows. Those run tests, lint, security scans — and report results as the green ✓ / red ✗ checks visible on the PR (lesson 0.4). Branch protection rules (lesson 0.9) can require those checks to pass before anyone can merge.

2. Actions can run agentic workflows. A workflow can call tools, invoke AI steps, or trigger on a schedule — so Actions isn't just the safety net around an agent's PR; it can be the agent. Both roles matter for GH-600.

The full safety chain: agent opens PR (event) → workflow triggers → job runs on runner → steps execute → checks appear on the PR → branch protection requires passing checks + human approval → then merge.

Check-in — three questions

Open-ended. Think first, then peek at the suggested answer.

1. Walk the chain. A teammate opens a pull request. Name the six things that happen in order before the green ✓ appears on the PR. (Try from memory first.)

   Suggested answer

   1. The pull_request event fires.
   2. GitHub finds a matching workflow file in .github/workflows/.
   3. The workflow is triggered and a runner (server) is booked for each job.
   4. The runner executes the job's steps in order — shell scripts or reusable actions.
   5. All steps pass → job succeeds; any step fails → job fails.
   6. The result posts as a check (green ✓ / red ✗) on the PR.

2. In your own words: what's the difference between a step and an action? Give one real example of each.

   Suggested answer

   A step is one item in the job's to-do list — it can be a shell script (npm test) or it can call a reusable action. An action is a pre-packaged, reusable block you drop into a step — like actions/checkout which checks out your code. Every action is used inside a step; not every step uses an action (some just run shell commands directly).

3. Tie it back to lesson 0.4. The robot worker opens a PR. Where do the green/red checks on that PR actually come from, and why does that matter before a human reviewer looks at it?

   Suggested answer

   Opening the PR fires a pull_request event, which triggers any workflow with on: pull_request. Those workflows run (tests, lint, security scans) on a runner and post their results as checks. This matters because branch protection rules (lesson 0.9) can require all checks to pass before the PR can be merged — so the automated rig acts as the first gate, catching problems before a human even opens the diff.

Mentor marks this lesson verified after you compare answers and say "got it" in chat.