GitLab CI/CD (.gitlab-ci.yml) Cheatsheet (helpful for junior DevOps)

First of all: What is .gitlab-ci.yml?


The .gitlab-ci.yml file is the configuration file that defines how our GitLab CI/CD (Continuous Integration and Continuous Deployment) pipeline runs.

It lives at the root of our GitLab repository and tells GitLab what jobs to run, in what order, under what conditions, and in what environments.

Purpose


When we push code to GitLab, the .gitlab-ci.yml file triggers pipelines that can automatically:

  • Build our application
  • Run tests
  • Deploy to staging or production
  • Analyze, or package code
  • Notify or perform other automated tasks

How It Works


  1. We commit a .gitlab-ci.yml file to our repository.
  2. GitLab reads it and creates a pipeline — a sequence of stages.
  3. Each stage runs jobs, which execute the commands we define (like npm test, docker build, etc.).
  4. Runners (machines provided by GitLab or our own servers) execute those jobs. e.g I covered setting up self-managed runner here:
Read more:Setup self-managed GitLab runner on AWS ec2 cloud – csforce.de | VIC: GitLab CI/CD (.gitlab-ci.yml) Cheatsheet (helpful for junior DevOps)

Example:

stages:
- build
- test
- deploy

build_app:
stage: build
script:
- echo "Building the app..."
- npm install && npm run build

test_app:
stage: test
script:
- echo "Running tests..."
- npm test

deploy_prod:
stage: deploy
script:
- echo "Deploying to production..."
- ./deploy.sh
only:
- main

Here is what we told GitLab PipeLine what to do per a set of instruction above using its .yml file aka .gitlab-ci.yml:

  • First, build_app runs (stage: build)
  • Then test_app runs (stage: test)
  • Finally, deploy_prod runs (stage: deploy) — but only when we push to the main branch

Here is the cheatsheet for all the keywords recognized by the pipeline and what are their purposes?

Anatomy & Basics

SectionPurpose / Notes
stages:Declare ordered stages (e.g. build, test, deploy). Jobs run by stage order.
variables:Global variables for jobs (unless overridden).
default:Default settings (e.g. image, before_script, cache) applied across jobs.
include:Pull in external YAML files (local, remote, template, project).
workflow:Define rules for when a pipeline should run (e.g. on merges only)

Job Configuration Keywords

Each job is a top-level key (except reserved ones). In a job we can use:

KeywordWhat it does / notes
stage:Assigns the job to one of the declared stages.
script:Required — commands to run. Can be an array or scalar.
image:Docker image to run the job in (if using Docker runner).
services:Additional Docker services (e.g. a database) for that job.
before_script: / after_script:Commands to run before / after script (per-job or inherited).
artifacts:Define files to keep from job (e.g. build outputs). Has subkeys like paths, expire_in, when.
cache:Define files/directories to cache between runs (e.g. dependencies).
dependencies:Jobs whose artifacts this job needs.
needs:More advanced — allows jobs to run out-of-stage order by declaring dependencies.
rules: / only: / except:Conditional logic to include/exclude job runs (by branch, tags, variables, etc.). Use rules: for more flexibility.
when:Defines job triggering: on_success, on_failure, always, manual, delayed.
allow_failure:Whether job failures are allowed without failing the pipeline.
timeout:Max time job can run.
environment:Set deployment environment (name, URL, etc.).
tags:Tags used to select appropriate runner(s).
retry:Retry configuration on failure (how many times, conditions).
parallel:Run multiple instances of the same job in parallel.
resource_group:Limit concurrency for jobs in the same resource group.
extends:Inherit from another job or template (for reuse).

This cheatsheet is helpful esp for engineer who just starts DevOps.

Example:

stages:
- build
- test
- deploy

variables:
APP_ENV: "production"

default:
image: node:18
before_script:
- npm ci

build_job:
stage: build
script:
- npm run build
artifacts:
paths:
- dist/

test_job:
stage: test
script:
- npm test
dependencies:
- build_job

deploy_job:
stage: deploy
script:
- ./deploy.sh
environment:
name: production
url: https://myapp.example.com
when: manual
only:
- main