Ejemplos de flujos CI/CD

Revisión de CódigoRevisión de MRs, análisis con IA y discusiones

Gestión de IssuesTriaje, seguimiento y gestión de proyectos

Ejemplos de usoReferencia rápida para todos los dominios

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

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

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

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

Prompt: “Obtén la salida del log del job ‘test-integration’ en el pipeline #45892”

job.trace → project_id: "my-group/backend", job_id: 98765

Devuelve: salida completa del log del job. Útil para diagnosticar fallos en tests sin abrir la interfaz de GitLab.

Empezar desde un recurso o un prompt

Un cliente que lee recursos MCP puede empezar por el último pipeline de la rama predeterminada sin ninguna llamada a herramienta y seguir después el mismo camino hasta el log:

1. Recurso: gitlab://project/42/pipelines/latest
   → ID, estado, ref, SHA, origen y URL web del último pipeline de la rama predeterminada
2. job.list → project_id: "42", pipeline_id: 100, scope: ["failed"]
3. job.trace → project_id: "42", job_id: 500
   → la salida de consola del job, para depurar

El prompt MCP summarize_pipeline_status (project_id) empaqueta los dos primeros pasos: agrupa hasta 100 jobs del mismo pipeline por resultado e incluye los motivos de fallo. Para un pipeline de otra rama, empieza por pipeline.latest con ese ref. Ambos necesitan la superficie de capacidades full predeterminada.

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

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

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: true

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

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

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

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

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

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

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

Prompt: “Detén el entorno review/feature-login en el proyecto backend”

environment.stop → project_id: "my-group/backend", environment_id: 42

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

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

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

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

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

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.

Mantenido por José Manuel Requena PlensGitHub LinkedIn Mastodon Google Scholar Todos los proyectos