Automate your checks with GitLab CI/CD — what pipelines, jobs, and stages are, a .gitlab-ci.yml written from scratch, a real Node.js pipeline, and watching runs from the terminal.
Why: CI/CD means a robot runs your checks (Continuous Integration) and ships your app (Continuous Delivery) on every push, so broken code is caught before anyone merges it. In GitLab you describe the robot's tasks in ONE file at the repo root — .gitlab-ci.yml — and a pipeline runs automatically on every push. GitLab.com provides the machines (called runners) for free. Note: this built-in CI/CD is the main reason teams pick GitLab.
# .gitlab-ci.yml — commit this file and GitLab runs it on every push
# A "job": a named task that runs on a fresh machine (a runner)
say-hello:
script:
- echo "GitLab CI is alive!"
- echo "This ran for commit $CI_COMMIT_SHORT_SHA"
# Watch it run: Build → Pipelines in the project's left sidebarWhy: stages run one after another, and jobs in the SAME stage run in parallel — so fast feedback (lint, tests) arrives together, and later work only happens if earlier work passed. If any job fails, later stages never run and the commit gets a red ✗.
# .gitlab-ci.yml
stages:
- build
- test
build-app:
stage: build
script:
- echo "Compiling…"
unit-tests:
stage: test
script:
- echo "Running unit tests…"
lint:
stage: test # same stage as unit-tests → they run in parallel
script:
- echo "Linting…"Why: a real job needs three things the hello-world version skipped — an image (the Docker container the job runs inside, here Node.js 22), a cache (so node_modules survives between runs instead of reinstalling every time), and your actual test command.
# .gitlab-ci.yml — for a typical Node.js project
stages:
- test
unit-tests:
stage: test
image: node:22 # the Docker image the job runs inside
cache:
key:
files:
- package-lock.json # new lockfile → fresh cache
paths:
- node_modules/ # kept between runs — much faster
before_script:
- npm ci # clean install from the lockfile
script:
- npm test
lint:
stage: test
image: node:22
before_script:
- npm ci
script:
- npm run lintWhy: every commit and MR shows its pipeline status — green check, red ✗, or a spinner. When something fails, the job log tells you exactly which command broke. The glab CLI brings the same view into your terminal.
In the browser: Build → Pipelines, or click the status icon shown next to any commit or merge request
From the terminal with glab:
glab ci statusglab ci viewRe-run the latest pipeline after a fix
glab ci retry