English for GitLab CI Developers

Master the English vocabulary developers need for discussing pipelines, stages, runners, and job dependencies when working with GitLab CI/CD.

GitLab CI’s pipeline model — stages, jobs, runners, artifacts — has enough of its own vocabulary that discussions can get vague fast if terms are used loosely. This guide covers the English used when discussing GitLab CI/CD pipelines with a team.

Key Vocabulary

Pipeline — the full run triggered by a commit or event, composed of stages that execute in order, each containing one or more jobs that can run in parallel. “This pipeline is failing at the deploy stage, but the build and test stages both passed — the problem is isolated to deployment, not the code itself.”

Stage — a named phase of a pipeline (build, test, deploy) that all jobs within it must complete before the next stage begins, the primary mechanism for sequencing. “Don’t put the smoke test in the same stage as deploy — if we want it to run strictly after deployment finishes, it needs its own later stage.”

Runner — the agent (shared or self-hosted) that actually executes pipeline jobs, tagged so specific jobs can target specific runner capabilities (GPU, specific OS). “This job is stuck in pending because it’s tagged for a runner type we don’t have registered — check the tags before assuming the pipeline itself is broken.”

Artifact — files produced by one job and passed forward to later jobs or stages, the mechanism for sharing build output without rebuilding it. “Don’t rebuild the app in the deploy job — the build job already produced it as an artifact; just download and use that.”

needs keyword (DAG pipeline) — a directive letting a job start as soon as its specific dependencies finish, rather than waiting for the entire previous stage to complete. “Add needs on this job so it can start as soon as its one dependency finishes, instead of waiting on the whole test stage to wrap up first.”

Pipeline cache — reusable, non-artifact data (dependencies, build tools) shared across pipeline runs to speed up jobs, distinct from artifacts which are scoped to a single pipeline run. “That ten-minute dependency install on every run is exactly what pipeline caching is for — cache the package directory keyed on the lockfile hash.”

Common Phrases

  • “Which stage is actually failing, and are the earlier stages confirmed green?”
  • “Is this job pending because of a runner tag mismatch, or is it a real queue backlog?”
  • “Are we rebuilding something here that a prior job already produced as an artifact?”
  • “Would needs let this job start earlier instead of waiting on the whole stage?”
  • “Is this dependency install being cached, or does every single run pay that cost from scratch?”

Example Sentences

Reviewing a pull request: “This new job doesn’t declare needs, so it’s waiting on the entire test stage even though it only actually depends on the lint job — that’s adding unnecessary pipeline time.”

Explaining a design decision: “We split deploy into its own stage after a smoke-test stage, so a bad deploy can be caught and rolled back before it’s marked as the final pipeline status.”

Describing an incident: “The deploy job kept using a stale artifact — a job earlier in the pipeline was failing silently, and dependent jobs were re-running against cached output from an older successful run.”

Professional Tips

  • Say “stage” and “job” precisely — a stage is a phase gate, a job is a unit of work within it; mixing them up causes real confusion when debugging pipeline order.
  • Name “runner tags” explicitly when a job is stuck pending — it’s one of the first things to check and a frequent source of confusion for newcomers.
  • Distinguish “artifact” from “cache” clearly — artifacts are pipeline-scoped output; cache is cross-run acceleration, and conflating them causes stale-build bugs.
  • Propose needs by name when a pipeline feels slower than it should — it’s the concrete mechanism for converting a linear pipeline into a faster DAG.

Practice Exercise

  1. Explain in two sentences why needs can make a pipeline faster than relying on stage order alone.
  2. Write a one-sentence code review comment flagging a job that rebuilds something already available as an artifact.
  3. Describe, in your own words, the difference between an artifact and a pipeline cache.