GitLab CI/CD: Pipelines, Stages, Jobs & Runners

Q: How is GitLab CI structured?

A pipeline is made of ordered stages, and each stage contains jobs that run in parallel. Jobs in a later stage start only after the previous stage succeeds. Everything is declared in one .gitlab-ci.yml file.

Q: What's the difference between artifacts and cache?

Artifacts are job outputs you intentionally pass downstream (build files, reports) and can download. Cache is a performance optimization that reuses things like dependency directories across runs. Don't rely on cache for correctness — it can be evicted.

GitLab CI/CD

GitLab CI/CD is the pipeline system built into GitLab. You define pipelines in a single .gitlab-ci.yml file at the repo root, and GitLab runners (hosted or self-managed) execute the jobs on every push, merge request, or schedule.

Because it's integrated with the rest of GitLab — merge requests, environments, the container registry — it offers a tightly-coupled, end-to-end DevOps experience without bolting on a separate CI service.

TL;DR

Pipelines are defined in .gitlab-ci.yml as ordered stages of jobs.
Runners execute jobs; artifacts pass files between jobs; cache speeds them up.
Run tests on merge requests; gate deploys with environments and approvals.
Prefer short-lived tokens/OIDC over long-lived secrets in CI variables.

Quick Example

A three-stage pipeline — build, test, deploy — with deploy restricted to the default branch:

Core Concepts

Pipeline — a full CI/CD run for a commit.
Stages — ordered phases (build → test → deploy); jobs in a stage run in parallel.
Jobs — individual units of work within a stage.
Runners — the machines (shared or self-hosted) that execute jobs.
Artifacts — files a job produces and passes to later jobs.
Cache — reused dependencies across runs to speed builds.

Best Practices

Run tests on merge requests so problems surface before merge.
Use separate deploy environments with manual approvals for production.
Keep jobs small and deterministic; declare dependencies explicitly.
Prefer OIDC/short-lived tokens over long-lived secrets in CI/CD variables.

Comparison: GitLab CI vs GitHub Actions

See GitHub Actions.

Common Mistakes

Caches that hide missing dependencies

Deploying from feature branches without guardrails

FAQ

How is GitLab CI structured?

A pipeline is made of ordered stages, and each stage contains jobs that run in parallel. Jobs in a later stage start only after the previous stage succeeds. Everything is declared in one .gitlab-ci.yml file.

What's the difference between artifacts and cache?

Artifacts are job outputs you intentionally pass downstream (build files, reports) and can download. Cache is a performance optimization that reuses things like dependency directories across runs. Don't rely on cache for correctness — it can be evicted.

Shared or self-hosted runners?

Shared (GitLab-hosted) runners need no maintenance and suit most teams. Self-hosted runners give control over hardware, private-network access, and cost at scale, but you operate and secure them. Watch for behavior differences between the two.

GitLab CI or GitHub Actions?

Use whichever matches your platform — they're comparable in capability. GitLab CI shines when you're all-in on GitLab's integrated DevOps (MRs, environments, registry). GitHub Actions shines in the GitHub ecosystem with its large Marketplace.