๐ 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 |
Top comments (2)
such amzing article on gitlab and the table is just amazing
Thank you.