Buildkite

官方

管理 Buildkite 流水线和构建。

GitHub
54

你可以用 Buildkite MCP 做什么？

  • 比较构建以发现回归 — 使用 compare_builds 并传入 org_slug、pipeline_slug 和 build_number，询问“自上次在 main 上正常工作的构建以来发生了什么变化？”
  • 通过日志调查失败的作业 — 在比较之后，使用 get_build_failure_summary 或 tail_logs 检查新失败或仍然失败的步骤的日志条目。
  • 固定特定基线进行比较 — 提供 baseline_build_number 以与特定构建进行比较，包括失败的构建或其他分支上的构建。
  • 理解作业匹配与计时 — 获取作业如何匹配（通过步骤键或名称回退）的详细信息，并查看从 scheduled_at 到 started_at 的执行时间差异。

文档

buildkite-mcp-server

Build status

Model Context Protocol (MCP) 服务器，向 AI 工具和编辑器暴露 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 KiB。设置 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 请求中的选定头转发到 Buildkite API：

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 请求使用各自的 Buildkite API 令牌进行身份验证，请允许 Authorization 并省略进程级令牌：

BUILDKITE_PASSTHROUGH_HTTP_HEADERS=Authorization \
  buildkite-mcp-server http

在此模式下，每个 /mcp 请求必须恰好包含一个非空的 Authorization 头。缺少凭据返回 HTTP 401；服务器永远不会回退到共享 API 令牌。MCP 服务器前面的反向代理负责对调用者进行身份验证，并设置或验证任何转发的身份头。

头传递在 stdio 模式下不可用。在提供作业日志之前，服务器会验证当前调用者是否可以访问该作业日志。此检查在每次日志工具请求时执行，即使日志数据已被缓存。

贡献

开发指南见 DEVELOPMENT.md。

许可证

MIT © Buildkite

SPDX-License-Identifier: MIT