Core Vocabulary
Six words are about to do a lot of heavy lifting for the next 70 chapters: workflow, job, step, runner, action, and event. They’re used precisely and consistently throughout GitHub’s own documentation, and this course will hold them to the same standard. Get comfortable with them now, because from Section B onward, none of them will be re-explained.
The Six Terms
Event — something that happens in your repository that GitHub Actions can react to. A push to a branch, a pull request being opened, a new issue being labeled, a release being published, or even a scheduled time of day. An event is the trigger — the thing that causes a workflow to start running in the first place. No event, no run.
Workflow — an automated process made up of one or more jobs, defined as a YAML file living in your repository, and set up to run in response to one or more events. A workflow is the top-level thing you’re building. When people casually say “the pipeline,” they usually mean the workflow.
Job — a set of steps that execute together, on the same runner, as a unit. A workflow can contain a single job or many jobs. By default, if a workflow has multiple jobs, they run independently of each other at the same time — you have to explicitly tell GitHub Actions if one job should wait for another to finish first.
Step — a single task within a job — the smallest unit of work in this whole hierarchy. A step can run a shell command directly, or it can use an action (see below) to do something more complex. Steps within the same job always run in order, one after another, on the same runner.
Runner — the actual machine — physical, virtual, or containerized — that executes a job’s steps. GitHub provides hosted runners for you, already set up with common tools installed, or you can register your own self-hosted runner if you need specific hardware, software, or network access that GitHub’s hosted machines don’t provide.
Action — a reusable, packaged unit of functionality that a step can use, instead of that step being just a raw shell command. Someone (GitHub, a third party, or you) builds an Action once — to check out your code, set up a specific language runtime, deploy to a cloud provider, whatever — and any workflow can reuse it with a single line, instead of everyone reimplementing the same logic by hand.
How They Fit Together
These six terms aren’t six unrelated concepts — they’re a strict hierarchy, with one term on the outside that starts everything off.
flowchart TD
Event([Event occurs<br/>e.g. push, pull request]) --> Workflow
subgraph Workflow[Workflow]
direction TB
subgraph JobB[Job B — runs independently, in parallel, by default]
direction TB
S4[Step 1: use an Action]
S5[Step 2: run a command]
S4 --> S5
end
subgraph JobA[Job A]
direction TB
S1[Step 1: run a command]
S2[Step 2: use an Action]
S3[Step 3: run a command]
S1 --> S2 --> S3
end
end
JobA -.executes on.-> RunnerA
JobB -.executes on.-> RunnerB
Reading this from the outside in: an event happens, which triggers a workflow. That workflow contains one or more jobs. Each job runs on its own runner and contains a sequence of steps, executed in order. Any individual step can either run a plain command directly, or invoke a reusable action to do the work instead.
Where People Get Tripped Up
A few points of confusion come up often enough to call out directly, before you carry a wrong mental model forward into the rest of the course.
“Workflow” and “pipeline” aren’t official synonyms, but you’ll hear them used that way. “Pipeline” is generic CI/CD terminology used across every tool in Chapter 3. “Workflow” is GitHub’s specific term for the same idea within Actions. This course uses “workflow” for precision, but don’t be thrown if a blog post or coworker says “pipeline” and means the exact same thing.
“Action” (capital-A, the reusable package) is easy to confuse with “GitHub Actions” (the product name) and with “action” as a plain English word (something a step does). All three appear constantly in the same sentences. A helpful mental anchor: if you can imagine reusing it as-is in someone else’s workflow, it’s an Action. If it’s just “run this shell command,” it’s a step that isn’t using an Action at all.
Jobs run in parallel by default, which surprises people expecting sequential execution. If Job B depends on something Job A produces, that dependency has to be stated explicitly — otherwise GitHub Actions will happily start both at the same time and Job B may run before Job A has produced anything it needs. This will matter a great deal once you’re building real, multi-job workflows.
A runner is infrastructure, not code. It’s easy to mentally lump “runner” in with the YAML concepts (workflow, job, step) since it’s configured alongside them, but a runner is the actual machine underneath — this distinction becomes important the moment you start choosing between hosted and self-hosted runners later in the course.
Tip
If you ever lose track of which term applies to what you’re looking at, ask yourself: “Is this the thing that started it all (event), the whole automated process (workflow), a chunk of that process running together on one machine (job), a single task inside that chunk (step), the machine itself (runner), or a reusable package a step can call on (action)?” That question covers all six, every time.
Disclosure on Closing Out
That’s the full landscape: what CI/CD is and why it exists, the real distinction between Integration, Delivery, and Deployment, a tour of the tools in the space, a case for and against GitHub Actions specifically, where it lives inside GitHub, and the vocabulary that names every piece of it. No YAML has been written yet — and that’s intentional. Next section is where that changes, and everything in it will assume the six terms from this chapter without re-explaining them, so this is worth revisiting if any of them still feel shaky before moving on.