Qué hace este generador
Un .gitlab-ci.yml vive en la raíz de tu repo GitLab y describe el pipeline completo: stages ordenados (install, test, deploy), jobs individuales con sus scripts, qué cachear y qué publicar como artifacts, y cuándo corre cada job realmente (¿solo en main? ¿solo en tags? ¿solo cuando cambia un fichero?). Es un solo fichero, sin UI separada, versionado con el resto del código.
Este generador escribe ese fichero por ti. Elige un preset (test + deploy, push a registry Docker, GitLab Pages), edita stages y jobs en formularios, y el panel derecho muestra el YAML exacto que puedes meter en `.gitlab-ci.yml`. El validador comprueba las trampas habituales: un job que necesita otro job en un stage posterior, un job referenciando un stage que no está en la lista `stages:`, nombres de job duplicados, jobs sin script.
Todo corre en tu navegador. Sin subidas, sin cuenta, no se inicia ningún pipeline real aquí. La salida es el mismo texto que escribirías a mano.
Cómo usarlo
- Elige un preset arriba: Test + deploy, push a registry Docker o GitLab Pages. El formulario rellena valores sensatos por defecto.
- Pon la image por defecto (usada por cada job que no la sobrescriba), la lista ordenada de stages y cualquier variable global como pares `KEY=value`.
- Añade jobs en pestañas. Para cada job pon: un nombre único, el stage al que pertenece (debe coincidir con uno de la lista de stages), un override de image opcional, variables opcionales y needs.
- Escribe el script (un comando por línea). Opcionalmente añade un before_script para comandos de setup compartidos entre ejecuciones.
- Configura artifacts (rutas y `expire_in`) para la salida del build. Configura cache con una clave y rutas para acelerar ejecuciones repetidas.
- Añade rules con expresiones `if:`, p. ej. `$CI_COMMIT_BRANCH == "main"`. Elige `on_success`, `always`, `manual` (requiere un clic para arrancar) o `never`.
- Activa allow_failure para jobs que no deberían bloquear el pipeline si fallan (linters, scanners de seguridad que son informativos).
- Pulsa Copiar en el panel de previsualización, o Descargar para guardar como `.gitlab-ci.yml`, luego commitea a la raíz de tu repositorio. El siguiente push dispara el pipeline.
Cuándo es útil
Siete situaciones concretas en las que un generador GitLab CI ahorra tiempo real:
- Primer pipeline en un proyecto nuevo. Elige "Test + deploy", cambia el comando de test, commitea. Listo en dos minutos en lugar de bucear por la larga documentación de GitLab.
- Añadir un push a registry Docker a un pipeline existente. El baile de login + tag + push es una secuencia conocida; el generador la escribe y tú solo rellenas el nombre de la imagen.
- Configurar un job de deploy que solo corre en main. La sintaxis `rules:` con `if:` es la moderna (reemplaza la vieja `only:` / `except:`), y pequeñas erratas desperdician una ejecución de pipeline completa.
- Cachear node_modules o pip entre ejecuciones del pipeline. La estanza cache es corta pero fácil de mal formatear. El generador escribe una caché funcional por defecto con la clave estándar `$CI_COMMIT_REF_SLUG`.
- Pipeline multi-stage con jobs paralelos en test. Varios jobs en el stage `test` corren en paralelo automáticamente. El generador hace la estructura obvia para que no los serialices accidentalmente.
- Una puerta de deploy manual. Pon la regla del job de deploy a `when: manual` y solo un clic explícito en la UI de GitLab arranca el deploy. Patrón común para prod.
- Deploy de un sitio GitLab Pages. El job especial `pages` tiene que publicar a `public/` como artifact. El preset "Pages deploy" codifica exactamente esa convención.