GitLab CI/CD Execution Hierarchy

Understanding the hierarchy, precedence, sequencing, and parallelism in GitLab CI/CD pipelines is crucial to mastering how your jobs run, how to optimize them, and how GitLab decides what to execute and when.

Here’s a complete and up-to-date (GitLab 18.0, May 2026) breakdown of the GitLab pipeline execution model:

🧱 1. 🔄 GitLab CI/CD Execution Hierarchy

➤ Pipeline (Top-Level Entity)

A single run of your .gitlab-ci.yml file. Triggered by:

• Push/merge/tag
• Schedule
• Manual trigger
• API call

➤ Stages (Sequential Execution Layer)

Defines the order of execution — each stage completes fully before the next begins.

stages:
  - lint
  - test
  - build
  - deploy

➤ Jobs (Inside Each Stage)

All jobs within a stage run in parallel, provided runners are available.

lint:
  stage: lint
  script: npm run lint

unit_test:
  stage: test
  script: npm test

➤ Steps inside a Job

Each job’s script: section contains commands that run sequentially inside the job’s shell or container.

🔃 2. Pipeline Execution Flow

Pipeline
 ├── Stage 1: lint
 │    ├── job: lint_a  (parallel)
 │    └── job: lint_b  (parallel)
 ├── Stage 2: test
 │    ├── job: unit_tests
 │    └── job: integration_tests
 ├── Stage 3: build
 │    └── docker_build
 └── Stage 4: deploy
      ├── job: staging_deploy
      └── job: prod_deploy (manual)

⏱️ 3. Job Precedence & Order of Execution

✅ Within a Stage:

• Jobs run in parallel
• No strict order unless using needs: (see below)

✅ Between Stages:

• Sequential: Stage 2 starts only if all Stage 1 jobs succeed

⚡ 4. How to Run Jobs in Parallel or Control Order

🔹 Parallel Jobs

Jobs in the same stage naturally run in parallel. Example:

test_backend:
  stage: test
  script: run backend tests

test_frontend:
  stage: test
  script: run frontend tests

🔹 Needs: (Run jobs out-of-order / faster)

Allows stage-skipping and job-level dependency. Ideal for reducing pipeline time.

unit_test:
  stage: test
  script: run tests

docker_build:
  stage: build
  script: build docker
  needs: [unit_test]   # Doesn't wait for whole test stage
Code language: PHP (php)

🔹 Dependencies (Job artifact consumption, older method)

Specify jobs that must complete before current job can use their artifacts.

deploy:
  stage: deploy
  dependencies: [build]
Code language: CSS (css)

🔁 Use needs: for parallel dependency-based optimization
📦 Use dependencies: to pass artifacts

🧪 5. Conditional Execution (Job-Level Control)

🔸 Rules

Recommended way to control job execution with complex conditions.

job_a:
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
Code language: JavaScript (javascript)

🔸 only/except (Deprecated in favor of rules)

job_b:
  only:
    - branches
    - tags

🎯 6. Extended Structures

📋 7. Visual: GitLab CI/CD Execution Hierarchy

Pipeline
├── Stages (sequential)
│   ├── Jobs (parallel unless controlled)
│   │   ├── Scripts (sequential commands)
│   │   └── Artifacts/Needs/Dependencies
├── Includes / Child Pipelines (optional)
└── Triggered Pipelines (optional)

✅ Summary: Controlling Flow & Parallelism

Rajesh Kumar

I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.

I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.