How complex have your pipelines on GitLab CI with includes and anchors been?

Worked with GitLab CI pipelines that use includes and anchors for structuring and reusing code in projects of varying complexity.

Typical use cases include: build pipelines for microservices with different environments (dev, staging, prod).

I use:

• External includes: for connecting common build, testing, deployment templates from a centralized repository.
• Local includes: for breaking down a large .gitlab-ci.yml into smaller, more readable parts (e.g., by build type or stage).
• Anchors (&) and references (*): for reusing repeating sections such as Docker image setup, common scripts, or task parameters.

Examples of complexity:

• Pipelines with branching logic depending on commit type, affected files, or branch.
• Using rules or only/except in conjunction with includes to include/exclude specific tasks or pipelines.
• Combining anchors and includes to create parameterized task templates that are easily reconfigured in child files.

# .gitlab-ci.yml - example structure
include:
  - project: 'common/ci-templates'
    ref: main
    file: '/templates/build-java.yml' # Common Java build template

  - local: '.gitlab-ci/deploy-prod.yml' # Local deployment file for prod

variables:
  SERVICE_NAME: my-service

stages:
  - build
  - test
  - deploy

# Using anchors for common settings
.base_job: &base_job
  image: ubuntu:latest
  before_script:
    - echo "Starting job..."

build-job:
  <<: *base_job # Applying the anchor
  stage: build
  script:
    - echo "Building $SERVICE_NAME"

# Task defined in include from common/ci-templates
# java-build:
#    <<: *base_job
#    stage: build
#    script:
#      - mvn clean package
# ... (other tasks)

Effectively using includes and anchors allows creating scalable, maintainable CI/CD pipelines, reducing code duplication, and simplifying configuration management. The complexity is usually determined by the number of services, technology diversity, and required pipeline flexibility.