Buildkite

buildkite-mcp-server

Model Context Protocol (MCP) सर्वर जो Buildkite डेटा (पाइपलाइन, बिल्ड, जॉब, टेस्ट) को AI टूलिंग और एडिटर्स के लिए उजागर करता है।

पूर्ण दस्तावेज़ buildkite.com/docs/apis/mcp-server पर उपलब्ध है।

---

बिल्ड की तुलना करना

investigations टूलसेट में केवल-पढ़ने वाला compare_builds टूल ऐसे प्रश्नों का उत्तर देता है जैसे "मुख्य शाखा पर यह बिल्ड पिछली बार काम करने के बाद से क्या बदला?" 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