Volver al blogEstudios de caso

Valida tu GitLab CI YAML antes de hacer push y evita errores

YAMLforge Team
14 min de lectura
yamljsondevops
Imagen de portada para GitLab CI YAML Validation Made Simple - Test Before You Push

Valida tu GitLab CI YAML antes de hacer push y evita errores

Trabaja más rápido: YAMLforge Pro elimina el límite de 10/día - convierte tantos archivos como necesites.

Subes tu código, esperas a que arranque el pipeline y... fallo inmediato. Error de sintaxis en la línea 42. Otra vez. Ahí van quince minutos que no volverás a recuperar.

→ Artículo relacionado: Convierte YAML a JSON al instante (herramienta gratuita)

Soy YF-kun 🤖 — ¡Te acompaño en este artículo! He depurado más problemas de indentación en YAML de los que me gustaría admitir, así que iré comentando cuando haya algo importante o simplemente interesante. Vamos a asegurarnos de que sus configuraciones de GitLab CI funcionen a la primera.

😅 YF-kun: Debug de configs a las 2am... todos hemos estado ahí.
😅 YF-kun: Una vez pasé dos horas depurando un pipeline solo para descubrir que había usado tabulaciones en lugar de espacios. ¿El mensaje de error? Completamente inútil. YAML es así de exigente.

¿Qué es la validación de YAML en GitLab CI?

GitLab CI usa un archivo .gitlab-ci.yml para definir su pipeline: qué trabajos se ejecutan, en qué orden y bajo qué condiciones. Este archivo YAML controla todo, desde ejecutar pruebas hasta desplegar a producción.

La validación verifica si la sintaxis de su YAML es correcta y cumple con las reglas específicas del esquema de GitLab. Puede detectar errores como claves faltantes, indentación incorrecta, nombres de trabajos no válidos o definiciones de etapas incorrectas antes de que rompan su pipeline real.

Piense en ello como un corrector ortográfico para su configuración de CI. No le dirá si su lógica es correcta, pero definitivamente le dirá si olvidó dos puntos o indentó algo mal.

🤔 YF-kun: El analizador YAML de GitLab es bastante estricto. Algunas cosas que funcionan en YAML normal no van a funcionar en una configuración de CI. Por ejemplo, no puede usar anclajes entre diferentes archivos con include. Esa la aprendí por las malas.
YAML server: port: 8080 host: localhost Convert JSON {"server": { "port": 8080, "host": "localhost"}}

Cómo validar su YAML de GitLab CI

🔓 Acceso ilimitado: Pro elimina el límite diario - convierte tantos archivos YAML como necesites.

Método 1: Herramienta CI Lint integrada en GitLab

GitLab proporciona una herramienta de validación dedicada en https://gitlab.com/[su-proyecto]/-/ci/lint. Puede acceder a ella desde la configuración de CI/CD de su proyecto.

Pasos:

  1. Navegue a su proyecto de GitLab
  2. Vaya a CI/CD → Editor o CI/CD → Pipelines → CI Lint
  3. Pegue el contenido de su YAML
  4. Haga clic en Validate

La herramienta le mostrará:

  • ✅ Errores de sintaxis con números de línea
  • ✅ Configuración expandida (con includes resueltos)
  • ✅ Cómo se verán las etapas y trabajos de su pipeline
💡 YF-kun: La herramienta CI Lint en realidad simula toda su configuración. Resuelve todos sus extends, declaraciones include y sustituciones de variables. Muy útil cuando trabaja con configuraciones complejas de múltiples archivos.

Método 2: Usar la API de GitLab

Para automatización o validación local, puede llamar directamente a la API de GitLab:

curl --header "Content-Type: application/json" \
     --header "PRIVATE-TOKEN: su_token" \
     --data '{"content": "su-yaml-aquí"}' \
     "https://gitlab.com/api/v4/ci/lint"

Esto devuelve JSON con el estado de validación y los errores encontrados.

🚀 YF-kun: Puede integrar esto en hooks de pre-commit. Valide localmente antes de hacer push y nunca más romperá el pipeline de sus compañeros. Se lo agradecerán.

Método 3: Usar YAMLforge para verificaciones rápidas de sintaxis

Mientras que las herramientas de GitLab verifican reglas específicas de GitLab, a veces solo necesita saber si su sintaxis YAML es válida. YAMLforge puede ayudarle con eso:

¿Necesitas automatización? Pro incluye integración API completa.

# Ejemplo .gitlab-ci.yml
stages:
  - build
  - test
  - deploy

build_job:
  stage: build
  script:
    - echo "Building the app"
    - npm install
    - npm run build
  artifacts:
    paths:
      - dist/

test_job:
  stage: test
  script:
    - npm test
  coverage: '/Coverage: \d+\.\d+%/'

deploy_job:
  stage: deploy
  script:
    - ./deploy.sh
  only:
    - main

Convierta a JSON con YAMLforge para detectar problemas estructurales:

{
  "stages": [
    "build",
    "test",
    "deploy"
  ],
  "build_job": {
    "stage": "build",
    "script": [
      "echo \"Building the app\"",
      "npm install",
      "npm run build"
    ],
    "artifacts": {
      "paths": [
        "dist/"
      ]
    }
  },
  "test_job": {
    "stage": "test",
    "script": [
      "npm test"
    ],
    "coverage": "/Coverage: \\d+\\.\\d+%/"
  },
  "deploy_job": {
    "stage": "deploy",
    "script": [
      "./deploy.sh"
    ],
    "only": [
      "main"
    ]
  }
}
🎯 YF-kun: Si YAMLforge no puede analizar su YAML a JSON válido, GitLab definitivamente no podrá usarlo. Es una verificación rápida antes de usar la herramienta CI Lint.
Step 1 Pegar YAML Step 2 Hacer clic en Validar Step 3 Corregir errores:Hacer push con confianza

Errores comunes en YAML de GitLab CI

1. Errores de indentación

YAML es sensible a los espacios en blanco. Mezcle la indentación y todo se rompe:

# ❌ Incorrecto - indentación inconsistente
build_job:
  stage: build
  script:
   - echo "Hello"  # Solo 1 espacio en lugar de 2
    - npm install  # 4 espacios - ¡inconsistente!
# ✅ Correcto - indentación consistente de 2 espacios
build_job:
  stage: build
  script:
    - echo "Hello"
    - npm install
⚠️ YF-kun: Use espacios, nunca tabulaciones. La mayoría de editores le permiten configurar esto. La extensión YAML de VS Code le avisará si mete la pata. En serio, actívela.

2. El Problema de Noruega en configuraciones de CI

Recuerde, YAML interpreta ciertas cadenas como booleanos:

# ❌ Esto falla de formas inesperadas
variables:
  DEPLOY_TO: NO  # ¡Se convierte en false!
  ENABLE_CACHE: YES  # ¡Se convierte en true!
  DEBUG_MODE: OFF  # ¡También se convierte en false!

GitLab leerá estos como valores booleanos, no como cadenas. Su script de despliegue que espera "NO" como cadena recibirá false en su lugar.

→ Ver también: Convertir YAML a JSON manteniendo las anclas intactas

# ✅ Entrecomíllelos para preservarlos como cadenas
variables:
  DEPLOY_TO: "NO"
  ENABLE_CACHE: "YES"
  DEBUG_MODE: "OFF"
😅 YF-kun: El Problema de Noruega ataca de nuevo. Una vez desplegué al entorno equivocado porque alguien puso PRODUCTION: NO sin comillas. El script de despliegue lo leyó como false (que es truthy en bash), y... sí. Producción recibió el build de desarrollo. Buenos tiempos.
The Norway Problem country: NO YAML parses this as: false (boolean) NO, Yes, Off = booleans! YAMLforge Solution country: "NO" Correctly preserved as: "NO" (string) Smart detection & quoting

3. Referencias a etapas no válidas

# ❌ El trabajo referencia una etapa que no existe
stages:
  - build
  - test

deploy_job:
  stage: deploy  # ¡Error! La etapa 'deploy' no está definida
  script:
    - ./deploy.sh
# ✅ Todas las etapas deben declararse primero
stages:
  - build
  - test
  - deploy  # Ahora está definida

deploy_job:
  stage: deploy
  script:
    - ./deploy.sh

4. Sintaxis incorrecta de only y except

# ❌ Incorrecto - only espera un array
deploy_job:
  stage: deploy
  only: main  # Esto no funcionará
  script:
    - ./deploy.sh
# ✅ Correcto - use sintaxis de array
deploy_job:
  stage: deploy
  only:
    - main  # Formato de array apropiado
  script:
    - ./deploy.sh

O mejor aún, use la sintaxis más nueva rules:

# ✅ Enfoque moderno con rules
deploy_job:
  stage: deploy
  script:
    - ./deploy.sh
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
💡 YF-kun: GitLab se está alejando de only y except hacia rules. Es más potente y mucho más legible. Puede combinar condiciones con && y ||, verificar variables, cambios en archivos, todo tipo de cosas.

Técnicas avanzadas de validación

Hooks de pre-commit con gitlab-ci-lint

Instale la herramienta CLI gitlab-ci-lint:

npm install -g gitlab-ci-lint

Cree un script .git/hooks/pre-commit:

#!/bin/bash

if [ -f .gitlab-ci.yml ]; then
  echo "Validando .gitlab-ci.yml..."
  gitlab-ci-lint .gitlab-ci.yml
  if [ $? -ne 0 ]; then
    echo "❌ La validación de GitLab CI falló. Corrija los errores antes de hacer commit."
    exit 1
  fi
  echo "✅ Validación de GitLab CI exitosa"
fi

Ahora no podrá hacer commit de configuraciones rotas aunque quiera.

Validación de esquema en su editor

La mayoría de editores modernos admiten validación de esquema YAML. Para VS Code, instale la extensión "YAML" de Red Hat, luego agregue a su configuración:

{
  "yaml.schemas": {
    "https://gitlab.com/gitlab-org/gitlab/-/raw/master/app/assets/javascripts/editor/schema/ci.json": ".gitlab-ci.yml"
  }
}

Obtendrá validación en tiempo real, autocompletado y documentación en línea mientras escribe.

🚀 YF-kun: Esto me cambió la vida. ¿Autocompletado para palabras clave de GitLab CI? ¿Documentación al pasar el cursor sobre propiedades de trabajos? Sí, por favor. Detecta el 90% de los errores antes de que guarde el archivo.

Consideraciones de privacidad y seguridad

Al validar configuraciones de CI, tenga en cuenta la seguridad:

  • Nunca pegue datos sensibles en herramientas de validación públicas
  • Elimine secretos antes de validar (use valores de marcador de posición)
  • Use las herramientas integradas de GitLab para configuraciones con información privada
  • YAMLforge procesa localmente: sus datos nunca salen de su navegador
🎯 YF-kun: En serio, no pegue sus claves API de producción en validadores en línea aleatorios. Lo he visto pasar. Use las herramientas propias de GitLab para cualquier cosa sensible, o use YAMLforge ya que es completamente del lado del cliente. Sus secretos permanecen secretos.

Comparación: CI Lint de GitLab vs. Validadores YAML generales

CaracterísticaCI Lint de GitLabYAMLforgeValidador YAML genérico
Verificación de sintaxis YAML
Validación de esquema de GitLab
Resuelve include
Expande variables
Procesamiento del lado del clienteVaría
Funciona sin conexión
Detección del Problema de Noruega
Mejor paraValidación finalVerificaciones de sintaxisAnálisis básico

Use CI Lint de GitLab para validación completa. Use YAMLforge para verificaciones rápidas de sintaxis y configuraciones sensibles a la privacidad. Use ambos para el mejor flujo de trabajo.

🎉 YF-kun: ¡Eso es todo! Ahora te toca a ti. ¡Éxito!
Why YAMLforge? 100% Client-side Norway Problem Fixed Free 10/day Date Safe Mode Schema Validation Pro: $9/month

Preguntas frecuentes

¿Cómo valido mi archivo YAML de GitLab CI?
Use la herramienta CI Lint integrada de GitLab en https://gitlab.com/[su-proyecto]/-/ci/lint. Pegue su YAML y haga clic en Validar. Verifica tanto la sintaxis como las reglas específicas del esquema de GitLab.

¿Puedo validar YAML de GitLab CI sin conexión?
Sí. Instale el paquete npm gitlab-ci-lint para validación local, o use plugins de editor como la extensión YAML de VS Code con el esquema de GitLab para validación en tiempo real mientras programa.

¿Cuál es la diferencia entre validación de YAML y validación de GitLab CI?
La validación de YAML verifica si su sintaxis es correcta (indentación, dos puntos, guiones). La validación de GitLab CI también verifica si está siguiendo el esquema de GitLab: nombres de trabajos válidos, referencias a etapas, sintaxis apropiada de rules, etc.

¿Por qué mi YAML válido falla en GitLab CI?
GitLab tiene requisitos específicos más allá de la sintaxis básica de YAML. Problemas comunes: etapas no definidas, palabras clave de trabajos no válidas, arrays incorrectos de only/except, o uso de características YAML no compatibles como anclajes entre archivos incluidos.

¿Es seguro pegar mi configuración de CI en validadores en línea?
Para configuraciones sin secretos, sí. Pero elimine cualquier token sensible, contraseñas o claves API primero. Mejor aún, use las herramientas propias de GitLab o validadores del lado del cliente como YAMLforge que nunca envían sus datos a un servidor.

→ Más información: Valida YAML de Kubernetes sin errores: guía completa

¿Qué es el Problema de Noruega en GitLab CI?
YAML convierte NO, YES, ON y OFF a booleanos a menos que estén entre comillas. En configuraciones de CI, esto puede romper variables de entorno o lógica condicional. Siempre entrecomille estos valores: DEPLOY: "NO" en lugar de DEPLOY: NO.

Comience a validar de manera más inteligente hoy

Ahora sabe cómo validar archivos YAML de GitLab CI como un profesional:

  • ✅ Use la herramienta CI Lint de GitLab para verificaciones completas
  • ✅ Detecte errores de sintaxis temprano con validación local
  • ✅ Evite errores comunes como el Problema de Noruega
  • ✅ Configure hooks de pre-commit para prevenir configuraciones rotas
  • ✅ Use esquemas de editor para validación en tiempo real
🎉 YF-kun: ¡Ya está listo! No más pipelines rotos por errores tontos de sintaxis. Y oye, si necesita verificar rápidamente sintaxis YAML o convertir formatos, YAMLforge está aquí para ayudar: totalmente gratis , sin necesidad de registrarse. ¡Ahora vaya y construya pipelines confiables!
¿Listo para probar? 10 conversiones gratis/día Empezar gratis →

¿Necesitas conversiones ilimitadas? Prueba YAMLforge Pro - acceso ilimitado, API, soporte prioritario y funciones de equipo. 9€/mes con garantía de devolución de 30 días.

Artículos relacionados

Y

YAMLforge Team

Equipo de contenido técnico

El equipo de YAMLforge ayuda apasionadamente a los desarrolladores a crear mejor software.

Probar YAMLforge gratis

Convierte YAML a JSON al instante con nuestra herramienta gratuita.

Probar YAMLforge gratis