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
- We commit a
.gitlab-ci.ymlfile to our repository. - GitLab reads it and creates a pipeline — a sequence of stages.
- Each stage runs jobs, which execute the commands we define (like
npm test,docker build, etc.). - 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_appruns (stage:build) - Then
test_appruns (stage:test) - Finally,
deploy_prodruns (stage:deploy) — but only when we push to themainbranch
Here is the cheatsheet for all the keywords recognized by the pipeline and what are their purposes?
Anatomy & Basics
| Section | Purpose / 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:
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
