English for GitHub Actions CI
Learn the English vocabulary for GitHub Actions: workflows, jobs, and runners, explained for discussing continuous integration pipelines clearly.
“The CI is broken” could mean the workflow file has a syntax error, a job failed, or a runner is stuck — GitHub Actions has specific terms for each layer, and using the right one gets a debugging conversation to the actual cause much faster.
Key Vocabulary
Workflow — a YAML file in .github/workflows/ defining an automated process, triggered by events like a push or pull request, containing one or more jobs.
“The deploy workflow triggers on every push to main, while the test workflow runs on every pull request instead.”
Job — a set of steps within a workflow that runs on a single runner, executing sequentially by default, with multiple jobs able to run in parallel unless explicit dependencies are declared. “We split lint and test into separate jobs so they run in parallel instead of one after the other, cutting the total pipeline time roughly in half.”
Runner — the virtual machine (or self-hosted machine) that actually executes a job’s steps, provisioned fresh for each run unless it’s a persistent self-hosted runner. “The build started failing only on the hosted runner, not locally — turned out the runner’s default Node version had changed after a GitHub-side update.”
Step — a single task within a job, either running a shell command directly or invoking a reusable action, executed in order within that job.
“The step that runs npm ci was failing because the lockfile was out of sync with package.json — a separate step further down never even got reached.”
Matrix build — a job configuration that runs the same steps across multiple combinations of variables (Node versions, operating systems), generating a separate job run per combination automatically. “We’re running a matrix build across Node 18, 20, and 22 so we catch version-specific bugs before they reach anyone actually running an older version.”
Common Phrases
- “Which job is actually failing — lint, test, or build?”
- “Is this a runner issue, or is the step itself failing?”
- “Can we parallelize these jobs instead of running them sequentially?”
- “Is this failure specific to one leg of the matrix build, or all of them?”
- “Which step in that job is the one throwing the error?”
Example Sentences
Triaging a failed pipeline in standup: “The deploy workflow is red, but it’s just the lint job — the actual build and test jobs both passed. Looks like a step is failing on a new ESLint rule, not an infrastructure problem.”
Explaining a flaky CI issue: “This only fails on the Windows leg of the matrix build, not Linux or macOS — it’s a path separator bug in the test itself, not a runner problem.”
Proposing a pipeline speedup: “Right now every job runs sequentially even though lint and unit tests don’t depend on each other. Splitting them into parallel jobs should cut our average CI time by a few minutes.”
Professional Tips
- Name the specific job that’s failing, not just “CI is red” — most workflows run several jobs, and pointing at the right one saves everyone a round trip through the logs.
- Distinguish a runner problem (environment, provisioning, quota) from a step problem (the actual command failing) when reporting a CI issue — they have completely different fixes.
- Mention which leg of a matrix build is failing specifically, since matrix failures are often environment-specific bugs rather than universal ones.
- Suggest parallelizing jobs explicitly when proposing pipeline speedups — it’s usually the single highest-leverage change for reducing total CI time.
Practice Exercise
- Write a sentence distinguishing a workflow from a job.
- Explain what a matrix build is used for.
- Describe the difference between a runner problem and a step problem.