🚀 Why GitLab CI/CD Over Jenkins and GitHub Actions?
| Feature | GitLab CI/CD | Jenkins | GitHub Actions |
|---|---|---|---|
| Integrated UI | ✅ Built-in | ❌ Plugin-based | ✅ Built-in |
| Auto DevOps | ✅ Native support | ❌ Manual | ❌ |
| Kubernetes Deployment | ✅ First-class | ✅ With plugins | ✅ Beta level |
| Security (Secrets, SAST, DAST) | ✅ Built-in | ❌ Manual config | ⚠️ External |
| Runners Management | ✅ Docker/Machine/K8s | ✅ Nodes | ✅ Hosted/self-hosted |
Why choose GitLab CI/CD?
Everything in one place (version control + CI/CD)
Great for GitOps and K8s-based workflows
Easy syntax, strong security model
No plugin hell like Jenkins
📁 Pipeline Basics
'# Comments'
Use # to write inline documentation.
# This job builds the project
build:
script:
- echo "Compiling..."
stages
Defines the execution order of jobs.
stages:
- build
- test
- deploy
stage
Assigns a job to a defined stage.
test:
stage: test
script: echo "Running tests"
script
Commands that the job will execute.
build:
stage: build
script:
- make build
🔀 Multi-Jobs in a Stage
build_app:
stage: build
script: make app
build_api:
stage: build
script: make api
⏳ timeout
Job-level timeout.
test:
script: run_tests
timeout: 30 minutes
📌 needs – Optimizing Pipeline Dependency
deploy:
stage: deploy
script: deploy.sh
needs: [build]
Use when job depends on output from another but not the full stage.
🧹 before_script and after_script
before_script:
- echo "Setup"
after_script:
- echo "Cleanup"
Used globally or at job level for pre/post commands.
📦 artifacts – Store Build Outputs
build:
script: make build
artifacts:
paths:
- dist/
expire_in: 1 week
🧬 variables – 5 Levels
Project-level: via GitLab UI → Settings → CI/CD → Variables
Used across all jobs.Global level:
variables:
ENV: production
Job-level:
test:
variables:
ENV: test
script: echo $ENV
Built-in:
$CI_PIPELINE_ID and $CI_COMMIT_BRANCH..............
From file:
variables:
CONFIG: config.yml
🛂 only and except (Deprecated → Use rules)
build:
script: build.sh
only:
- main
📜 rules, if, and when
test:
script: test.sh
rules:
- if: '$CI_COMMIT_BRANCH == "main"'
when: always
🏃 Run File Inside Script
script:
- chmod +x ./deploy.sh
- ./deploy.sh
🔁 workflow – Pipeline Start Conditions
workflow:
rules:
- if: '$CI_COMMIT_BRANCH == "main"'
when: always
- when: never
🐳 image – Docker Environment
image: python:3.9
script:
- pip install -r requirements.txt
🔢 Matrix/Loops (via parallel:matrix)
job:
stage: test
parallel:
matrix:
- VARIANT: [A, B, C]
script:
- echo $VARIANT
🌐 Multi-Project Pipelines
trigger-downstream:
stage: trigger
trigger:
project: other-group/other-project
branch: main
📦 Downloading/Packaging in a Pipeline
build:
script:
- wget https://example.com/app.tar.gz
- tar -xzf app.tar.gz
⏰ Pipeline Scheduling
Go to GitLab UI → CI/CD → Schedules
workflow:
rules:
- if: '$CI_PIPELINE_SOURCE == "schedule"'
when: always
🏃 GitLab Runner Types
| Runner Type | Description | Use Case |
|---|---|---|
| Shared Runners | Maintained by GitLab | Quick use, limited config |
| Group Runners | Shared by a group | Org-level control |
| Project Runners | Bound to a project | Isolation, security |
| Docker Executor | Containers | Microservices, clean env |
| Shell Executor | Host machine | Full access needed |
| Kubernetes Executor | Pods on K8s | Cloud-native CI/CD |