Запускайте Binlog MCP Server в CI для автоматической диагностики ошибок сборки

2026-06-30 команда .NET опубликовала MCP Beyond the Chat Window: Build Diagnostics in CI, и это выносит Binlog MCP Server из вашего редактора и помещает в ваш pipeline. Две недели назад этот сервер был тем, на что вы вручную направляли Claude или Copilot из локального .binlog (эту настройку я разобрал в статье Binlog MCP Server позволяет ИИ читать ваши логи MSBuild). Новая демонстрация запускает его без надзора в GitHub Actions: сборка падает, агент читает лог, и комментарий с первопричиной появляется в pull request раньше, чем кто-либо что-либо скачает.

Почему CI — лучшее место для binlog

Интерактивный сценарий хорош, но настоящая боль — в CI. Сборка становится красной, вы вытягиваете с runner двоичный лог в несколько мегабайт, открываете MSBuild Structured Log Viewer и прокручиваете вложенные targets в поисках той единственной ошибки, которая важна. Перенос парсера в pipeline устраняет весь этот цикл. .binlog никогда не покидает runner, а чтение выполняет модель.

Лог вы по-прежнему генерируете тем же способом. Добавьте /bl к любой команде на основе MSBuild:

dotnet build /bl
dotnet test /bl
dotnet pack /bl

Подключение к GitHub Agentic Workflow

Ключевое отличие в том, что сервер поставляется как образ контейнера, поэтому workflow монтирует лог в режиме только для чтения и позволяет агенту к нему обращаться. Репозиторий microsoft/testfx использует примерно такую форму:

mcp-servers:
  binlog-mcp:
    container: "mcr.microsoft.com/dotnet-buildtools/prereqs:azurelinux-3.0-binlog-mcp-amd64"
    mounts:
      - "/tmp/build.binlog:/data/build.binlog:ro"
    allowed: ["*"]

Job запускает сборку с двоичным логом, и только когда сборка падает, он будит агента. На зелёном ничего не запускается, поэтому за прошедшие сборки вы не платите никаких затрат на токены.

binlog_diagnose делает первый проход

Инструмент, который делает это практичным, — binlog_diagnose. Вместо того чтобы агент сам сцеплял binlog_errors, binlog_search и binlog_target_reasons, binlog_diagnose читает лог, группирует ошибки, определяет вероятную первопричину и предлагает исправление за один вызов. Остальной набор (binlog_overview, binlog_compare, binlog_task_details и растущий список других инструментов для производительности, графов зависимостей и интроспекции инкрементальных сборок) остаётся на месте, когда агенту нужно копнуть глубже.

В собственной оценке Microsoft передача агенту этих инструментов подняла оценку качества диагностики с 3.25 до 3.68 по сравнению с базовой линией без инструментов, и он завершил работу примерно на 44% быстрее (196s vs 350s общего времени). Быстрее и лучше — редкое сочетание, и оно возникает оттого, что агент запрашивает структурированные данные, а не делает grep по сырому тексту лога.

Если у вас есть нестабильная сборка в CI, которая раз за разом производит лог, который никто не хочет открывать, это тот вариант настройки, который действительно экономит время вашей команде: сортировка происходит автоматически, в PR, пока сбой ещё свеж.