GitLab CI for Monorepos with Path-Based Triggering

Monorepo Pipeline Configuration

In a monorepo, running all jobs on every commit wastes CI resources. GitLab CI's rules:changes keyword lets you trigger jobs only when specific paths change.

Pipeline Configuration

stages:
  - build
  - test
  - deploy

# Frontend jobs
build_frontend:
  stage: build
  image: node:20-alpine
  script:
    - cd frontend && npm ci && npm run build
  artifacts:
    paths:
      - frontend/dist/
  rules:
    - changes:
        - frontend/**/*
        - shared/**/*

test_frontend:
  stage: test
  image: node:20-alpine
  script:
    - cd frontend && npm ci && npm test
  needs:
    - job: build_frontend
      optional: true
  rules:
    - changes:
        - frontend/**/*
        - shared/**/*

# Backend jobs
build_backend:
  stage: build
  image: golang:1.22-alpine
  script:
    - cd backend && go build -o app ./cmd/server
  artifacts:
    paths:
      - backend/app
  rules:
    - changes:
        - backend/**/*
        - shared/**/*

test_backend:
  stage: test
  image: golang:1.22-alpine
  script:
    - cd backend && go test ./...
  needs:
    - job: build_backend
      optional: true
  rules:
    - changes:
        - backend/**/*
        - shared/**/*

Key Concepts

rules:changes: Jobs only run when files matching the glob pattern have changed in the commit. This dramatically reduces pipeline duration for monorepos.

Shared dependencies: Both frontend and backend jobs trigger on shared/**/* changes, ensuring that shared library modifications are tested by all consumers.

optional: true on needs: When a needed job is skipped (because its rules:changes did not match), the downstream job would normally fail. The optional: true flag allows the downstream job to run anyway.

Caveats

• rules:changes compares against the previous commit on the same branch, not against the merge request target. For MR pipelines, use rules:changes:compare_to.
• The first pipeline on a new branch always evaluates all paths as changed.