Buildkite

oficial

Gerenciar pipelines e builds do Buildkite.

O que você pode fazer com Buildkite MCP?

Compare builds to find regressions — Pergunte "O que mudou desde que este build funcionou pela última vez na main?" usando compare_builds com org_slug, pipeline_slug e build_number.
Investigate failing jobs with logs — Use get_build_failure_summary ou tail_logs para examinar entradas de log de etapas que falharam recentemente ou que continuam falhando após uma comparação.
Pin a specific baseline for comparison — Forneça baseline_build_number para comparar com um build específico, incluindo os que falharam ou builds em outras branches.
Understand job matching and timing — Obtenha detalhes sobre como os jobs são correspondidos (via step keys ou fallback de nome) e veja os deltas de tempo de execução de scheduled_at até started_at.

Documentação

buildkite-mcp-server

Model Context Protocol (MCP) servidor que expõe dados do Buildkite (pipelines, builds, jobs, testes) para ferramentas de IA e editores.

Documentação completa disponível em buildkite.com/docs/apis/mcp-server.

Comparando builds

A ferramenta somente leitura compare_builds do conjunto de ferramentas investigations responde perguntas como "O que mudou desde que este build funcionou pela última vez na main?" Forneça org_slug, pipeline_slug e o build_number de destino. Ela seleciona o build anterior mais recente que está atualmente aprovado no mesmo pipeline e na mesma branch exata. Não é necessário que o baseline já tivesse passado quando o destino foi iniciado. Forneça baseline_build_number para comparar com um build específico nesse pipeline, incluindo um build com falha ou um em outra branch.

A resposta identifica o baseline e a regra de seleção, conta os resultados em todos os jobs e retorna até 100 comparações de jobs, priorizando etapas com falha recente, recuperadas e ainda com falha. A correspondência usa chaves de etapa, tipo de job, valores de matriz e índice/total paralelo. Quando ambos os jobs não possuem chaves, ela recorre ao nome não vazio exato mais o tipo, chave de grupo, valores de matriz e índice/total paralelo, somente quando essa combinação é única em cada build. Pares correspondidos expõem match_method: "step_key" ou "name_fallback"; correspondências de fallback trazem um aviso de que são heurísticas. Jobs sem nome e sem chave e identidades duplicadas permanecem sem correspondência. Chaves explícitas nunca recorrem a nomes, mesmo quando uma chave foi adicionada, removida ou alterada entre builds. Adicionado/removido significa que uma identidade de job está presente em apenas um build, portanto renomear jobs sem chave ou alterar valores de matriz ou paralelismo também pode gerar entradas adicionadas/removidas. Tentativas repetidas são excluídas; os estados da tentativa final e as contagens de repetição permanecem visíveis.

Os tempos de execução e deltas cobrem apenas as tentativas finais. O tempo de agendamento é scheduled_at a started_at, não espera de dependência ou manual. Estas não são comparações de tempo de parede do build nem custos totais de repetição. Timestamps ausentes ou inconsistentes omitem o tempo correspondente. Builds não concluídos são explicitamente identificados como snapshots em mudança.

Transições entre falhas suaves e graves são relatadas como state_changed, mesmo quando ambos os jobs têm estado failed. Um build baseline aprovado pode conter jobs com falha suave.

Por padrão, até três jobs com falha recente incluem suas últimas 20 entradas de log, limitadas a 8 KiB de conteúdo de log cada. Defina include_logs: false para omitir logs. Erros de log não descartam a comparação, exceto erros de autenticação HTTP 401, que se propagam pelo caminho de reautenticação do servidor. A ferramenta requer escopos read_builds e read_build_logs. Use get_build_failure_summary ou tail_logs para investigar mais; uma etapa com falha compartilhada não estabelece uma causa raiz comum nem torna uma repetição segura.

A descoberta de baseline pesquisa no máximo 500 candidatos. Se nenhum for encontrado, a resposta diz que nenhuma comparação foi realizada e pede um baseline explícito. Os inventários de jobs são limitados a 1.000 jobs por build; inventários maiores retornam um erro em vez de resultados parciais enganosos de adicionados/removidos. Omissões de saída são relatadas separadamente das contagens completas de resultados.

Uso da Biblioteca

A API Go exportada deste módulo deve ser considerada instável e sujeita a mudanças disruptivas à medida que evoluímos este projeto.

Segurança

Para garantir que o servidor MCP seja executado em um ambiente seguro, recomendamos executá-lo em um contêiner.

Esta imagem é construída a partir de cgr.dev/chainguard/static e é executada como um usuário sem privilégios.

Encaminhando cabeçalhos de identidade pelo modo HTTP

Implantações HTTP auto-hospedadas podem encaminhar cabeçalhos selecionados de cada solicitação MCP recebida para a API do Buildkite:

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

Repita --passthrough-http-header para permitir mais de um cabeçalho, ou defina um valor BUILDKITE_PASSTHROUGH_HTTP_HEADERS separado por vírgulas. Somente cabeçalhos explicitamente permitidos são encaminhados, e somente para a origem configurada por BUILDKITE_BASE_URL. Eles são removidos de solicitações redirecionadas para outro lugar.

Para autenticar cada solicitação MCP com seu próprio token de API do Buildkite, permita Authorization e omita o token de todo o processo:

BUILDKITE_PASSTHROUGH_HTTP_HEADERS=Authorization \
  buildkite-mcp-server http

Neste modo, toda solicitação /mcp deve conter exatamente um cabeçalho Authorization não vazio. Credenciais ausentes retornam HTTP 401; o servidor nunca recorre a um token de API compartilhado. O proxy reverso na frente do servidor MCP é responsável por autenticar os chamadores e definir ou validar quaisquer cabeçalhos de identidade encaminhados.

O encaminhamento de cabeçalhos não está disponível no modo stdio. Antes de servir logs de jobs, o servidor verifica se o chamador atual pode acessar o log do job. Essa verificação é realizada para cada solicitação de ferramenta de log, inclusive quando os dados de log já estão em cache.

Contribuindo

As diretrizes de desenvolvimento estão em DEVELOPMENT.md.

Licença

SPDX-License-Identifier: MIT