Buildkite

공식

Buildkite 파이프라인과 빌드를 관리합니다.

GitHub

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

Model Context Protocol (MCP) 서버로, Buildkite 데이터(파이프라인, 빌드, 작업, 테스트)를 AI 도구 및 편집기에 노출합니다.

전체 문서는 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까지이며, 종속성 또는 수동 대기 시간은 포함하지 않습니다. 이는 빌드 벽시계 시간 비교 또는 총 재시도 비용이 아닙니다. 누락되거나 일관되지 않은 타임스탬프는 해당 타이밍을 생략합니다. 완료되지 않은 빌드는 변경 중인 스냅샷으로 명시적으로 식별됩니다.

소프트 실패와 하드 실패 간의 전환은 두 작업 모두 상태가 failed인 경우에도 state_changed로 보고됩니다. 통과된 기준 빌드에는 소프트 실패한 작업이 포함될 수 있습니다.

기본적으로 최대 3개의 새로 실패한 작업에는 각각 마지막 20개의 로그 항목이 포함되며, 각 로그 콘텐츠는 8KiB로 제한됩니다. 로그를 생략하려면 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 모드에서 ID 헤더 전달

자체 호스팅 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 서버 앞의 리버스 프록시는 호출자를 인증하고 전달된 ID 헤더를 설정하거나 검증할 책임이 있습니다.

헤더 전달은 stdio 모드에서 사용할 수 없습니다. 작업 로그를 제공하기 전에 서버는 현재 호출자가 작업 로그에 액세스할 수 있는지 확인합니다. 이 확인은 로그 데이터가 이미 캐시된 경우를 포함하여 모든 로그 도구 요청에 대해 수행됩니다.

기여

개발 지침은 DEVELOPMENT.md에 있습니다.

라이선스

SPDX-License-Identifier: MIT