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 del catálogo que el servidor ejecuta, escrita como dominio.acción → parámetros: en la superficie dinámica predeterminada es el action que pasas a gitlab_execute_action, y con GITLAB_MCP_TOOL_SURFACE=meta es el action de la meta-herramienta gitlab_<dominio>, 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”
pipeline.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”
job.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”
job.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?”
ci_variable.list → project_id: "my-group/backend"Devuelve: claves de variables, valores, estado de protección, estado de enmascaramiento y ámbitos de entorno. El valor llega tal como GitLab se lo devuelve al token, así que trata la salida como sensible.
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”
ci_variable.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”
ci_variable.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”
pipeline.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”
pipeline.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”
environment.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”
environment.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”
environment.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”
template.lint_project → 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 la frecuencia de despliegue del proyecto backend durante enero”
dora_metrics.project → project_id: "my-group/backend", metric: "deployment_frequency", start_date: "2024-01-01", end_date: "2024-01-31"Devuelve: una serie de valores diarios de la métrica solicitada. metric es obligatorio y admite uno de deployment_frequency, lead_time_for_changes, time_to_restore_service o change_failure_rate, así que las cuatro métricas son cuatro llamadas.
Métricas a nivel de grupo
Sección titulada «Métricas a nivel de grupo»Prompt: “Compara la tasa mensual de fallo en cambios entre todos los proyectos del grupo platform”
dora_metrics.group → group_id: "platform", metric: "change_failure_rate", interval: "monthly"Devuelve: la métrica agregada para todo el grupo por intervalo, ú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í que los IDs domain.action anteriores son exactamente lo que pasa a gitlab_execute_action. 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. Ejecuta pipeline.list con status: failed para localizar la ejecución, job.list con el ID del pipeline para ver qué job falló, y después job.trace para obtener la traza de ese job y que el asistente lea el error real. En la superficie dinámica predeterminada son acciones de gitlab_execute_action; con GITLAB_MCP_TOOL_SURFACE=meta son la acción list de gitlab_pipeline y las acciones list y trace de gitlab_job. 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í. pipeline.retry y pipeline.cancel actúan sobre un pipeline, y job.retry y job.cancel sobre un job concreto (las acciones retry y cancel de las meta-herramientas gitlab_pipeline y gitlab_job cuando GITLAB_MCP_TOOL_SURFACE=meta). 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_MCP_READ_ONLY=true y devuelven una previsualización con GITLAB_MCP_SAFE_MODE=true.
¿Cómo valido mi configuración de CI antes de hacer push?
Usa la acción template.lint (gitlab_execute_action en la superficie predeterminada; gitlab_template con action: lint cuando GITLAB_MCP_TOOL_SURFACE=meta; la herramienta gitlab_ci_lint en la superficie individual) 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 ci_variable.list (gitlab_ci_variable con action: list en la superficie meta) 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_MCP_READ_ONLY=true para que ninguna variable pueda crearse ni modificarse.