Pipelines Avanzados

Parent-Child Pipelines

Un pipeline puede disparar sub-pipelines definidos en otros archivos YAML.

Caso de uso

Monorepo con frontend y backend:

# .gitlab-ci.yml (parent)
stages:
  - triggers

frontend:
  stage: triggers
  trigger:
    include: frontend/.gitlab-ci.yml
    strategy: depend
  rules:
    - changes:
        - "frontend/**/*"

backend:
  stage: triggers
  trigger:
    include: backend/.gitlab-ci.yml
    strategy: depend
  rules:
    - changes:
        - "backend/**/*"

# frontend/.gitlab-ci.yml (child)
stages:
  - test
  - build

test:
  image: node:20-alpine
  script:
    - cd frontend && npm ci && npm test

build:
  image: node:20-alpine
  script:
    - cd frontend && npm run build

strategy: depend hace que el parent espere al child y herede su estado (pass/fail).

Pipelines generados dinamicamente

generate_config:
  stage: build
  script:
    - python generate_ci.py > generated.yml
  artifacts:
    paths:
      - generated.yml

run_generated:
  stage: test
  trigger:
    include:
      - artifact: generated.yml
        job: generate_config

Multi-project Pipelines

Dispara un pipeline en otro proyecto.

deploy_infra:
  trigger:
    project: devops/infrastructure
    branch: main
    strategy: depend
  variables:
    APP_VERSION: $CI_COMMIT_TAG

Casos de uso

• Deploy trigger: el repo de la app dispara el pipeline de infraestructura
• Integracion: testear que los cambios no rompen proyectos dependientes
• Release: coordinar deploys entre microservicios

Merge Trains

Los merge trains aseguran que cada MR pasa CI con los cambios anteriores incluidos.

Sin merge trains:
  MR-1 pasa ✅ → merge
  MR-2 pasa ✅ → merge  (puede romper porque MR-1 cambio algo)

Con merge trains:
  MR-1 pasa ✅ → merge
  MR-2 se re-testea con MR-1 incluido ✅ → merge

Activar

1. Settings > Merge Requests > Merge trains enabled
2. En .gitlab-ci.yml:

test:
  script:
    - npm test
  rules:
    - if: $CI_MERGE_REQUEST_EVENT_TYPE == "merge_train"
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

Pipelines por Compliance

Para organizaciones que necesitan que ciertos jobs siempre se ejecuten:

# Compliance pipeline (configurado por admins del grupo)
include:
  - project: security/compliance-templates
    file: /sast.yml

# Los proyectos no pueden saltarse estos jobs

Se configura en Group Settings > General > Compliance frameworks.

Patron: Pipeline completo de produccion

workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == "main"
    - if: $CI_COMMIT_TAG =~ /^v\d+\.\d+\.\d+$/

stages:
  - install
  - quality
  - build
  - deploy

install:
  stage: install
  image: node:20-alpine
  cache:
    key:
      files: [package-lock.json]
    paths: [node_modules/]
  script:
    - npm ci
  artifacts:
    paths: [node_modules/]
    expire_in: 30 min

lint:
  stage: quality
  needs: [install]
  script:
    - npm run lint

test:
  stage: quality
  needs: [install]
  services:
    - postgres:16-alpine
  script:
    - npm run test:ci
  artifacts:
    reports:
      junit: junit.xml

build:
  stage: build
  needs: [lint, test]
  script:
    - npm run build
  artifacts:
    paths: [dist/]
    expire_in: 1 week

deploy_production:
  stage: deploy
  needs: [build]
  script:
    - ./deploy.sh
  environment:
    name: production
    url: https://app.example.com
  rules:
    - if: $CI_COMMIT_TAG =~ /^v\d+\.\d+\.\d+$/
      when: manual

---

Siguiente: Capitulo 10: Runners en Kubernetes →