Buildkite

oficial

Gestiona pipelines y builds de Buildkite.

¿Qué puedes hacer con Buildkite MCP?

Comparar builds para encontrar regresiones — Pregunta "¿Qué cambió desde que este build funcionó por última vez en main?" usando compare_builds con org_slug, pipeline_slug y build_number.
Investigar trabajos fallidos con registros — Usa get_build_failure_summary o tail_logs para examinar entradas de registro de pasos que fallan recientemente o que siguen fallando después de una comparación.
Fijar una línea base específica para la comparación — Proporciona baseline_build_number para comparar contra un build en particular, incluidos los fallidos o builds en otras ramas.
Entender la coincidencia de trabajos y el tiempo — Obtén detalles sobre cómo se emparejan los trabajos (mediante claves de paso o respaldo por nombre) y observa las diferencias de tiempo de ejecución desde scheduled_at hasta started_at.

Documentación

buildkite-mcp-server

Protocolo de Contexto de Modelo (MCP) servidor que expone datos de Buildkite (pipelines, builds, jobs, tests) a herramientas de IA y editores.

La documentación completa está disponible en buildkite.com/docs/apis/mcp-server.

Comparando builds

La herramienta de solo lectura compare_builds en el conjunto de herramientas investigations responde preguntas como "¿Qué cambió desde que este build funcionó por última vez en main?" Proporcione org_slug, pipeline_slug y el build_number objetivo. Selecciona el build anterior más recientemente creado que actualmente haya pasado en el mismo pipeline y rama exacta. No requiere que la línea base ya hubiera pasado cuando el objetivo comenzó. Proporcione baseline_build_number para comparar contra un build específico en ese pipeline en su lugar, incluido un build fallido o uno en otra rama.

La respuesta identifica la línea base y la regla de selección, cuenta los resultados en todos los jobs y devuelve hasta 100 comparaciones de jobs, priorizando pasos recién fallidos, recuperados y aún fallidos. La coincidencia utiliza claves de paso, tipo de job, valores de matriz e índice/total paralelo. Cuando ambos jobs carecen de claves, recurre al nombre no vacío exacto más el tipo, clave de grupo, valores de matriz e índice/total paralelo, solo cuando esa combinación es única en cada build. Los pares coincidentes exponen match_method: "step_key" o "name_fallback"; las coincidencias de respaldo llevan una advertencia de que son heurísticas. Los jobs sin nombre y sin clave y las identidades duplicadas permanecen sin coincidencia. Las claves explícitas nunca recurren a nombres, incluso cuando se agregó, eliminó o cambió una clave entre builds. Agregado/eliminado significa que una identidad de job está presente en solo un build, por lo que renombrar jobs sin clave o cambiar valores de matriz o paralelismo también puede producir entradas agregadas/eliminadas. Los intentos reintentados se excluyen; los estados del intento final y los recuentos de reintentos permanecen visibles.

Los tiempos de ejecución y los deltas cubren solo los intentos finales. El tiempo de programación es scheduled_at a started_at, no espera de dependencia o manual. Estas no son comparaciones de tiempo de pared del build ni costos totales de reintento. Las marcas de tiempo faltantes o inconsistentes omiten el tiempo correspondiente. Los builds no terminados se identifican explícitamente como instantáneas cambiantes.

Las transiciones entre fallos suaves y duros se informan como state_changed, incluso cuando ambos jobs tienen estado failed. Un build de línea base aprobado puede contener jobs con fallo suave.

De forma predeterminada, hasta tres jobs recién fallidos incluyen sus últimas 20 entradas de registro, limitadas a 8 KiB de contenido de registro cada una. Establezca include_logs: false para omitir registros. Los errores de registro no descartan la comparación, excepto los errores de autenticación HTTP 401, que se propagan a través de la ruta de reautenticación del servidor. La herramienta requiere los alcances read_builds y read_build_logs. Use get_build_failure_summary o tail_logs para investigar más a fondo; un paso fallido compartido no establece una causa raíz compartida ni hace que un reintento sea seguro.

El descubrimiento de la línea base busca como máximo 500 candidatos. Si no se encuentra ninguno, la respuesta dice que no se realizó ninguna comparación y solicita una línea base explícita. Los inventarios de jobs se limitan a 1,000 jobs por build; los inventarios más grandes devuelven un error en lugar de resultados parciales engañosos de agregado/eliminado. Las omisiones de salida se informan por separado de los recuentos de resultados completos.

Uso de la biblioteca

La API Go exportada de este módulo debe considerarse inestable y sujeta a cambios disruptivos a medida que evolucionamos este proyecto.

Seguridad

Para garantizar que el servidor MCP se ejecute en un entorno seguro, recomendamos ejecutarlo en un contenedor.

Esta imagen se construye desde cgr.dev/chainguard/static y se ejecuta como un usuario sin privilegios.

Pasando encabezados de identidad a través del modo HTTP

Las implementaciones HTTP autohospedadas pueden reenviar encabezados seleccionados de cada solicitud MCP entrante a la API de Buildkite:

BUILDKITE_API_TOKEN=bkua_xxx \
  buildkite-mcp-server http \
  --passthrough-http-header X-User-Identity

Repita --passthrough-http-header para permitir más de un encabezado, o establezca un valor BUILDKITE_PASSTHROUGH_HTTP_HEADERS separado por comas. Solo se reenvían los encabezados explícitamente permitidos, y solo al origen configurado por BUILDKITE_BASE_URL. Se eliminan de las solicitudes redirigidas a otro lugar.

Para autenticar cada solicitud MCP con su propio token de API de Buildkite, permita Authorization y omita el token de todo el proceso:

BUILDKITE_PASSTHROUGH_HTTP_HEADERS=Authorization \
  buildkite-mcp-server http

En este modo, cada solicitud /mcp debe contener exactamente un encabezado Authorization no vacío. Las credenciales faltantes devuelven HTTP 401; el servidor nunca recurre a un token de API compartido. El proxy inverso frente al servidor MCP es responsable de autenticar a los llamadores y establecer o validar cualquier encabezado de identidad reenviado.

El paso de encabezados no está disponible en modo stdio. Antes de servir registros de jobs, el servidor verifica que el llamador actual pueda acceder al registro del job. Esta verificación se realiza para cada solicitud de herramienta de registro, incluso cuando los datos del registro ya están en caché.

Contribuyendo

Las pautas de desarrollo están en DEVELOPMENT.md.

Licencia

SPDX-License-Identifier: MIT