Validación de archivos GitLab CI con linter antes del pipeline

Validar la configuración de GitLab CI sin esperar a que corra un pipeline completo es clave para trabajar rápido y con confianza. Aquí verás cómo usar el linter de GitLab CI para detectar errores de sintaxis en .gitlab-ci.yml, cuáles ajustes mínimos asegurar para un Pipeline verde, y qué ocurre al integrar cambios con squash commits y merge a master.

¿Cómo validar .gitlab-ci.yml con el linter de GitLab CI?

Usar primero el linter evita perder tiempo en ejecuciones fallidas por errores de sintaxis. GitLab ofrece un validador que confirma si los keywords, el orden y la estructura del archivo .gitlab-ci.yml son correctos. Ojo: el linter valida sintaxis, no la lógica de tus scripts.

• Entra al proyecto y abre el linter en la ruta: /-/ci/lint.
• Copia y pega todo tu .gitlab-ci.yml y presiona Validar.
• Corrige errores de sintaxis como artificts por artifacts.
• Repite la validación hasta obtener “syntaxis correcta”.

Con la sintaxis lista, confirma cambios en Git:

• Revisa con git status que .gitlab-ci.yml está listo para stage.
• Añade y crea el commit: “add GitLab CI config”.
• Firma con tu llave PGP si tu repositorio lo requiere.
• Sube cambios con git push usando tu llave SSH.

¿Qué configuración mínima asegura un pipeline estable en Node?

La configuración base incluye la imagen Node 11, dos stages (Install y Test) y jobs bien encadenados mediante artifacts y dependencies. Esto garantiza que node_modules se comparta correctamente y que las pruebas corran sin reinstalar todo en cada job.

• Imagen base: Node 11.
• Stages: Install y Test.
• Job “Install dependencies”: instala dependencias y las exporta como artifacts para los siguientes jobs.
• Uso de cache para evitar reinstalaciones de node_modules.
• Job de tests: pertenece a stage “test” y depende de “install dependencies” vía dependencies para consumir node_modules.

Ajustes críticos en el job de pruebas:

• before_script: instalar Chrome correctamente. Corregir “app get” por apt-get update y usar && en lugar de &&&.
• script: ejecutar npm run test CI en lugar de “npm test CI”.
• variables: declarar la variable de ambiente que apunta al binario de Chrome para que Karma ejecute en Chrome Headless. Sin esto, los tests no corren.

Ideas clave que garantizan estabilidad:

• El linter detecta sintaxis, pero no errores en los scripts.
• Artifacts y dependencies conectan jobs y comparten node_modules.
• Cache acelera el pipeline evitando reinstalaciones.
• Chrome Headless permite correr pruebas sin interfaz gráfica.
• npm run test CI respeta la convención de npm scripts.

¿Qué sucede tras un pipeline verde y el merge a master?

Desde el menú de Pipelines verás primero el job de instalación y la subida de artifacts. Luego el job de tests instala Chrome y ejecuta las pruebas. Al terminar con “tres success”, el widget del merge request muestra el Pipeline en verde.

Cambios revisados antes de integrar:

• Añadir .gitlab-ci.yml con toda la configuración.
• Agregar un script en package.json para pruebas.
• Configurar Karma para correr en Chrome Headless.

Buenas prácticas al integrar:

• Resolver el estado WIP cuando el pipeline está verde.
• Hacer squash commits para mantener un historial claro.
• Borrar el branch tras el merge.

Tras confirmar el merge, se detona automáticamente un pipeline en master porque la configuración ya vive ahí. Esto consolida el primer paso de Continuous Integration: con cada commit se instalan dependencias y corren los tests. Más adelante podrás integrar Continuous Deployment y Continuous Delivery dentro de tu flujo de development.

¿Te gustaría comentar cómo declaras tus variables o cómo optimizas el uso de artifacts y cache en tus pipelines de GitLab CI?