Buildkite

официальный

Управление пайплайнами и сборками Buildkite.

Что можно делать с Buildkite MCP?

Сравнение сборок для поиска регрессий — Задайте вопрос «Что изменилось с тех пор, как эта сборка в последний раз работала на main?» с помощью compare_builds, указав org_slug, pipeline_slug и build_number.
Анализ упавших заданий с помощью логов — Используйте get_build_failure_summary или tail_logs для изучения записей логов по шагам, которые упали недавно или продолжают падать после сравнения.
Закрепление конкретной базовой сборки для сравнения — Укажите baseline_build_number, чтобы сравнивать с конкретной сборкой, включая упавшие или сборки из других веток.
Понимание сопоставления заданий и таймингов — Получите сведения о том, как сопоставляются задания (по ключам шагов или с запасным вариантом по имени), и посмотрите разницу во времени выполнения от scheduled_at до started_at.

Документация

buildkite-mcp-server

Model Context Protocol (MCP) сервер, предоставляющий данные Buildkite (пайплайны, сборки, задания, тесты) для ИИ-инструментов и редакторов.

Полная документация доступна на buildkite.com/docs/apis/mcp-server.

Сравнение сборок

Инструмент только для чтения compare_builds в наборе инструментов investigations отвечает на такие вопросы, как «Что изменилось с момента последней успешной сборки на main?». Укажите org_slug, pipeline_slug и целевую build_number. Инструмент выбирает самую последнюю созданную более раннюю сборку, которая в настоящее время прошла на том же пайплайне и той же точной ветке. Не требуется, чтобы базовая сборка уже прошла на момент запуска целевой. Укажите baseline_build_number, чтобы сравнить с конкретной сборкой в этом пайплайне, включая неудачную сборку или сборку на другой ветке.

Ответ определяет базовую сборку и правило выбора, подсчитывает результаты по всем заданиям и возвращает до 100 сравнений заданий, отдавая приоритет недавно упавшим, восстановленным и всё ещё падающим шагам. Сопоставление использует ключи шагов, тип задания, значения матрицы и параллельный индекс/общее количество. Когда у обоих заданий нет ключей, используется точное непустое имя плюс тип, ключ группы, значения матрицы и параллельный индекс/общее количество, но только если такая комбинация уникальна в каждой сборке. Сопоставленные пары раскрывают match_method: "step_key" или "name_fallback"; резервные совпадения сопровождаются предупреждением о том, что они эвристические. Безымянные задания без ключей и дублирующиеся идентификаторы остаются несопоставленными. Явные ключи никогда не заменяются именами, даже если ключ был добавлен, удалён или изменён между сборками. Добавленные/удалённые означают, что идентичность задания присутствует только в одной сборке, поэтому переименование заданий без ключей или изменение значений матрицы или параллелизма также может привести к появлению добавленных/удалённых записей. Повторные попытки исключаются; состояния финальных попыток и количество повторов остаются видимыми.

Время выполнения и дельты охватывают только финальные попытки. Время планирования — это scheduled_at до started_at, а не ожидание зависимостей или ручное ожидание. Это не сравнение времени сборки по часам и не общая стоимость повторов. Отсутствующие или противоречивые временные метки пропускают соответствующие данные о времени. Незавершённые сборки явно идентифицируются как изменяющиеся снимки.

Переходы между мягкими и жёсткими сбоями сообщаются как state_changed, даже если оба задания имеют состояние failed. Прошедшая базовая сборка может содержать задания с мягким сбоем.

По умолчанию до трёх недавно упавших заданий включают последние 20 записей журнала, ограниченных 8 КиБ содержимого журнала каждое. Установите include_logs: false, чтобы исключить журналы. Ошибки журнала не отменяют сравнение, кроме ошибок аутентификации HTTP 401, которые передаются через путь повторной аутентификации сервера. Инструмент требует области read_builds и read_build_logs. Используйте get_build_failure_summary или tail_logs для дальнейшего расследования; общий упавший шаг не устанавливает общую первопричину и не делает повторную попытку безопасной.

Поиск базовой сборки проверяет не более 500 кандидатов. Если ни один не найден, ответ сообщает, что сравнение не выполнялось, и запрашивает явную базовую сборку. Инвентаризации заданий ограничены 1 000 заданий на сборку; более крупные инвентаризации возвращают ошибку вместо вводящих в заблуждение частичных результатов добавления/удаления. Пропуски вывода сообщаются отдельно от полных подсчётов результатов.

Использование библиотеки

Экспортируемый Go API этого модуля следует считать нестабильным и подверженным критическим изменениям по мере развития проекта.

Безопасность

Чтобы обеспечить работу MCP-сервера в безопасной среде, мы рекомендуем запускать его в контейнере.

Этот образ построен из cgr.dev/chainguard/static и запускается от непривилегированного пользователя.

Передача заголовков идентификации через HTTP-режим

Самостоятельно размещённые HTTP-развёртывания могут пересылать выбранные заголовки из каждого входящего MCP-запроса в API Buildkite:

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

Повторите --passthrough-http-header, чтобы разрешить более одного заголовка, или установите значение BUILDKITE_PASSTHROUGH_HTTP_HEADERS через запятую. Пересылаются только явно разрешённые заголовки, и только к источнику, настроенному через BUILDKITE_BASE_URL. Они удаляются из запросов, перенаправляемых в другое место.

Чтобы аутентифицировать каждый MCP-запрос с собственным токеном API Buildkite, разрешите Authorization и опустите общепроцессный токен:

BUILDKITE_PASSTHROUGH_HTTP_HEADERS=Authorization \
  buildkite-mcp-server http

В этом режиме каждый запрос /mcp должен содержать ровно один непустой заголовок Authorization. Отсутствующие учётные данные возвращают HTTP 401; сервер никогда не переключается на общий токен API. Обратный прокси перед MCP-сервером отвечает за аутентификацию вызывающих и установку или проверку любых пересылаемых заголовков идентификации.

Передача заголовков недоступна в режиме stdio. Перед предоставлением журналов заданий сервер проверяет, что текущий вызывающий может получить доступ к журналу задания. Эта проверка выполняется для каждого запроса инструмента журнала, включая случаи, когда данные журнала уже кэшированы.

Вклад в разработку

Руководство по разработке находится в DEVELOPMENT.md.

Лицензия

SPDX-License-Identifier: MIT