How do you optimize GitLab CI/CD pipeline performance for a large monorepo?

In a monorepo, the biggest performance killer is running every job for every change, even when a commit only touched one small service out of dozens in the repository. Optimization mostly comes down to running less work, running it in parallel, and reusing what's already been built.

• Rules with changes - only run a service's jobs when files under its path actually changed, using rules: - changes: [services/api/**], instead of running the whole suite on every commit.
• DAG pipelines with needs - let jobs start as soon as their specific dependencies finish, instead of waiting for an entire stage to complete.
• Parallel jobs - split large test suites using parallel: so GitLab spins up several runner instances of the same job, each handling a slice of the tests.
• Aggressive, well-scoped caching - cache dependency directories per-service with keys tied to that service's lockfile, so unrelated services don't invalidate each other's cache.
• Runner fleet sizing - add more concurrent runners (or autoscaling Kubernetes runners) so parallel/DAG jobs aren't just queued waiting for capacity.

The combination that tends to matter most in practice is changes-based rules plus DAG needs: together they stop unrelated services from being rebuilt and let genuinely independent jobs run concurrently instead of being serialized by stage boundaries that don't reflect real dependencies.