Ejemplos de flujos CI/CD
Estos flujos CI/CD paso a paso muestran cómo diagnosticar fallos de pipelines, gestionar variables CI/CD, programar builds, controlar entornos, validar la configuración y leer métricas DORA — todo en lenguaje natural. Cada ejemplo combina el prompt que escribes con la acción exacta de meta-tool que el servidor ejecuta, para que veas con precisión qué ocurre por debajo y puedas reutilizar la llamada directamente.
Diagnosticar un pipeline fallido
Sección titulada «Diagnosticar un pipeline fallido»Cuando un pipeline falla, este flujo te lleva desde la lista de pipelines fallidos hasta el log del job concreto que explica el fallo — sin salir de tu asistente. Lista los pipelines fallidos, profundiza en los jobs que fallan y luego lee el log del job para encontrar la causa raíz.
Obtener resumen de pipelines
Sección titulada «Obtener resumen de pipelines»Prompt: “Muéstrame todos los pipelines fallidos en my-group/backend”
gitlab_pipeline → action: list, project_id: "my-group/backend", status: "failed"Devuelve: IDs de pipelines, ramas, razones de fallo y duraciones.
Investigar un pipeline fallido
Sección titulada «Investigar un pipeline fallido»Prompt: “Muéstrame los jobs fallidos en el pipeline #45892”
gitlab_job → action: list, project_id: "my-group/backend", pipeline_id: 45892, scope: "failed"Devuelve: nombres de jobs, stages, mensajes de error e información del runner.
Leer logs de jobs
Sección titulada «Leer logs de jobs»Prompt: “Obtén la salida del log del job ‘test-integration’ en el pipeline #45892”
gitlab_job → action: trace, project_id: "my-group/backend", job_id: 98765Devuelve: salida completa del log del job. Útil para diagnosticar fallos en tests sin abrir la interfaz de GitLab.
Gestionar variables CI/CD
Sección titulada «Gestionar variables CI/CD»Configura el entorno en el que se ejecutan tus pipelines listando, creando y acotando variables CI/CD. Úsalo para inspeccionar lo que ya está definido, añadir secretos como tokens de despliegue con enmascaramiento y protección, o restringir una variable a un único entorno.
Listar variables del proyecto
Sección titulada «Listar variables del proyecto»Prompt: “¿Qué variables CI/CD están configuradas en el proyecto backend?”
gitlab_ci_variable → action: project_list, project_id: "my-group/backend"Devuelve: claves de variables, estado de protección, estado de enmascaramiento y ámbitos de entorno. Los valores están enmascarados por seguridad.
Añadir variable de despliegue
Sección titulada «Añadir variable de despliegue»Prompt: “Añade una variable CI/CD DEPLOY_TOKEN con valor ‘abc123’ al proyecto backend, enmascarada y protegida”
gitlab_ci_variable → action: project_create, project_id: "my-group/backend", key: "DEPLOY_TOKEN", value: "abc123", masked: true, protected: trueActualizar ámbito de variable
Sección titulada «Actualizar ámbito de variable»Prompt: “Actualiza la variable DATABASE_URL en backend para que solo aplique al entorno de producción”
gitlab_ci_variable → action: project_update, project_id: "my-group/backend", key: "DATABASE_URL", environment_scope: "production"Programación de pipelines
Sección titulada «Programación de pipelines»Automatiza pipelines recurrentes con programaciones basadas en cron —por ejemplo, un build nocturno— y revisa qué programaciones ya existen y cuándo se ejecutarán a continuación.
Crear build nocturno
Sección titulada «Crear build nocturno»Prompt: “Crea una programación de pipeline que se ejecute cada noche a las 2 AM UTC en la rama main”
gitlab_pipeline → action: schedule_create, project_id: "my-group/backend", description: "Nightly build", ref: "main", cron: "0 2 * * *", cron_timezone: "UTC"Listar programaciones activas
Sección titulada «Listar programaciones activas»Prompt: “Muéstrame todas las programaciones de pipeline en el proyecto backend”
gitlab_pipeline → action: schedule_list, project_id: "my-group/backend"Devuelve: descripciones, expresiones cron, próximas ejecuciones e información del propietario.
Gestión de entornos
Sección titulada «Gestión de entornos»Controla y sigue dónde se despliega tu código. Lista los entornos para ver su estado y sus URLs, revisa el historial de despliegues de producción y detén los entornos de revisión efímeros cuando ya no se necesiten.
Listar entornos
Sección titulada «Listar entornos»Prompt: “Muéstrame todos los entornos del proyecto backend”
gitlab_environment → action: list, project_id: "my-group/backend"Devuelve: nombres de entornos, URLs externas, información del último despliegue y estado.
Consultar historial de despliegues
Sección titulada «Consultar historial de despliegues»Prompt: “Muéstrame los despliegues recientes al entorno de producción”
gitlab_environment → action: deployment_list, project_id: "my-group/backend", environment: "production"Detener un entorno de revisión
Sección titulada «Detener un entorno de revisión»Prompt: “Detén el entorno review/feature-login en el proyecto backend”
gitlab_environment → action: stop, project_id: "my-group/backend", environment_id: 42Validar configuración CI
Sección titulada «Validar configuración CI»Detecta errores de .gitlab-ci.yml antes de que rompan un pipeline validando la configuración. El servidor devuelve el estado de validación junto con el YAML totalmente fusionado, para que confirmes que los includes y las plantillas se resuelven como esperas.
Lint de configuración CI
Sección titulada «Lint de configuración CI»Prompt: “Valida el .gitlab-ci.yml en my-group/backend buscando errores de sintaxis”
gitlab_template → action: ci_lint, project_id: "my-group/backend"Devuelve: estado de validación, YAML fusionado, advertencias y detalles de errores.
Métricas DORA
Sección titulada «Métricas DORA»Mide el rendimiento de entrega con las cuatro métricas DORA —frecuencia de despliegue, tiempo de entrega para cambios, tiempo de restauración del servicio y tasa de fallo en cambios— a nivel de proyecto o de grupo. Las métricas DORA requieren una licencia de GitLab Premium o Ultimate.
Rendimiento del proyecto
Sección titulada «Rendimiento del proyecto»Prompt: “Muéstrame las métricas DORA del proyecto backend en los últimos 30 días”
gitlab_dora_metrics → action: project, project_id: "my-group/backend", metric: "all", start_date: "2024-01-01", end_date: "2024-01-31"Devuelve: frecuencia de despliegue, tiempo de entrega para cambios, tiempo de restauración del servicio y tasa de fallo en cambios.
Métricas a nivel de grupo
Sección titulada «Métricas a nivel de grupo»Prompt: “Compara las métricas DORA entre todos los proyectos del grupo platform”
gitlab_dora_metrics → action: group, group_id: "platform", metric: "all", interval: "monthly"Devuelve: métricas agregadas para todo el grupo, útil para dashboards de liderazgo de ingeniería.
Llamadas CI/CD dinámicas primero
Sección titulada «Llamadas CI/CD dinámicas primero»En la superficie dinámica predeterminada, el asistente descubre primero la acción CI/CD exacta y su esquema, y luego la ejecuta — así los prompts anteriores se resuelven a IDs canónicos domain.action en lugar de a meta-herramientas con nombre. El patrón de dos pasos es buscar y luego ejecutar:
gitlab_find_action → query: "estado del último pipeline del proyecto"gitlab_execute_action → action: "pipeline.latest", params: { project_id: "42" }Para jobs fallidos, descubre primero la acción de log o reintento y luego ejecuta con el schema devuelto:
gitlab_find_action → query: "obtener trace de job fallido"gitlab_execute_action → action: "job.trace", params: { project_id: "42", job_id: 9876 }Preguntas frecuentes
¿Cómo depuro un pipeline de GitLab que falla con un asistente de IA?
Se baja desde el pipeline hasta el log del job. Llama a gitlab_pipeline con action: list y status: failed para localizar la ejecución, a gitlab_job con action: list y el ID del pipeline para ver qué job falló, y después a gitlab_job con action: trace para obtener la traza de ese job y que el asistente lea el error real. En la superficie dinámica son pipeline.list, job.list y job.trace. Leer el log es el paso decisivo: el estado del pipeline rara vez explica el fallo.
¿Puede un asistente de IA reintentar o cancelar un pipeline?
Sí. gitlab_pipeline acepta action: retry y action: cancel, y gitlab_job admite las mismas dos para un job concreto. Reintentar un pipeline vuelve a ejecutar solo sus jobs fallidos, mientras que reintentar un job vuelve a ejecutar únicamente ese job. Ambas son acciones mutantes, así que no están disponibles con GITLAB_READ_ONLY=true y devuelven una previsualización con GITLAB_SAFE_MODE=true.
¿Cómo valido mi configuración de CI antes de hacer push?
Usa gitlab_ci_lint para validar .gitlab-ci.yml contra el propio linter de GitLab sin llegar a commitear nada. Informa de errores de sintaxis y de la configuración fusionada tras resolver los include:, que es la forma más rápida de detectar un extends: roto o una errata en el nombre de un job. Como solo valida, está disponible en despliegues de solo lectura.
¿El asistente de IA puede ver los valores de las variables CI/CD?
Listar variables con gitlab_ci_variable y action: list devuelve los valores que el token tenga permiso para leer, así que trata esa salida como sensible: las variables enmascaradas y protegidas se rigen por las reglas de GitLab, no por el servidor MCP. Si un asistente no debe verlas nunca, usa un token sin el scope necesario, o ejecuta con GITLAB_READ_ONLY=true para que ninguna variable pueda crearse ni modificarse.