Buildkite

ทางการ

จัดการไปป์ไลน์และบิลด์ของ Buildkite

คุณทำอะไรได้บ้างด้วย Buildkite MCP?

เปรียบเทียบ builds เพื่อค้นหาปัญหาที่เกิดขึ้น — ถามว่า "มีอะไรเปลี่ยนแปลงไปตั้งแต่ build นี้ทำงานสำเร็จครั้งล่าสุดบน main?" โดยใช้ compare_builds พร้อมกับ org_slug, pipeline_slug และ build_number
ตรวจสอบ jobs ที่ล้มเหลวด้วย logs — ใช้ get_build_failure_summary หรือ tail_logs เพื่อตรวจสอบรายการ log สำหรับขั้นตอนที่เพิ่งล้มเหลวหรือยังคงล้มเหลวหลังจากการเปรียบเทียบ
กำหนด baseline เฉพาะสำหรับการเปรียบเทียบ — ระบุ baseline_build_number เพื่อเปรียบเทียบกับ build ที่เฉพาะเจาะจง รวมถึง build ที่ล้มเหลวหรือ build บน branch อื่น ๆ
ทำความเข้าใจการจับคู่ jobs และระยะเวลา — ดูรายละเอียดว่า jobs ถูกจับคู่อย่างไร (ผ่าน step keys หรือ name fallback) และดูความแตกต่างของเวลาดำเนินการจาก 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 ไม่ใช่การรอการพึ่งพาหรือการรอด้วยตนเอง สิ่งเหล่านี้ไม่ใช่การเปรียบเทียบเวลาจริงของบิลด์หรือต้นทุนการลองใหม่ทั้งหมด การประทับเวลาที่ขาดหายไปหรือไม่สอดคล้องกันจะละเว้นเวลาที่เกี่ยวข้อง บิลด์ที่ยังไม่เสร็จจะถูกระบุอย่างชัดเจนว่าเป็นสแนปช็อตที่เปลี่ยนแปลง

การเปลี่ยนระหว่างความล้มเหลวแบบอ่อนและแบบแข็งจะรายงานเป็น 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

ใบอนุญาต

SPDX-License-Identifier: MIT