19 दिस॰ 2025·6 मिनट
CI विफलताओं के लिए Claude Code: छोटे फिक्स + टेस्ट
CI विफलताओं के लिए Claude Code: विफल आउटपुट को उद्धृत करने का निर्देश दें, सबसे छोटा फिक्स सुझाएँ, और दोहराव रोकने के लिए एक रिग्रेशन टेस्ट जोड़ें।
CI विफलताओं के लिए Claude Code: विफल आउटपुट को उद्धृत करने का निर्देश दें, सबसे छोटा फिक्स सुझाएँ, और दोहराव रोकने के लिए एक रिग्रेशन टेस्ट जोड़ें।
एक CI विफलता आमतौर पर रहस्यमयी नहीं होती। लॉग बताती है जहाँ काम रुका, कौन-सा कमांड फेल हुआ, और त्रुटि संदेश क्या है। एक अच्छा रन स्टैक ट्रेस, compiler error में फ़ाइल और लाइन नंबर, या टेस्ट रिपोर्ट जिसमें कौन-सा assertion फेल हुआ दिखाता है। कभी-कभी आपको diff-स्टाइल संकेत भी मिलते हैं जैसे "expected X, got Y" या एक स्पष्ट फेलिंग स्टेप जैसे "lint", "build", या "migrate database"।
असल समस्या यह है कि लोग (और AI) अक्सर लॉग को बैकग्राउंड नॉइज़ समझ लेते हैं। अगर आप लंबा लॉग पेस्ट कर देते हैं और बस "एक फिक्स" पूछते हैं, तो कई मॉडल आख़िरी सार्थक लाइनों को पढ़ने की बजाय किसी परिचित स्पष्टीकरण पर कूद जाते हैं। अनुमान और भी खराब होते हैं जब त्रुटि सामान्य लगती है ("module not found", "timeout", "permission denied"). नतीजा एक बड़ा रीराइट, एक नया डिपेंडेंसी, या "सब कुछ अपडेट करके देखें" जैसा उत्तर होता है जो असली विफलता से मेल नहीं खाता।
लक्ष्य "किसी तरह पास कराओ" नहीं है। यह सरल है:
अमल में, "सबसे छोटा फिक्स" आमतौर पर इनमें से एक होता है: एक जगह पर कुछ लाइन का कोड परिवर्तन, एक मिसिंग import या गलत पाथ, CI वातावरण के लिए स्पष्ट रूप से गलत कोई कॉन्फ़िग वैल्यू, या डिजाइन बदलने के बजाय एक आकस्मिक ब्रेकिंग चेंज को उलटना।
एक फॉलो‑अप टेस्ट भी मायने रखता है। CI एक बार पास होना ही रिपीट्स रोकना नहीं है। अगर विफलता किसी एज‑केस (null इनपुट, टाइमज़ोन, राउंडिंग, परमिशन्स) की वजह से आई थी, तो एक रिग्रेशन टेस्ट जोड़ें जो फिक्स से पहले फेल और फिक्स के बाद पास हो। इससे एक बार का रेस्क्यू गार्डरेल में बदल जाता है।
ज़्यादातर बुरे फिक्स़्स की शुरुआत मिसिंग कॉन्टेक्स्ट से होती है। अगर आप केवल आख़िरी लाल लाइन चिपकाते हैं, तो मॉडल को अनुमान लगाना पड़ेगा कि पहले क्या हुआ, और अनुमान अक्सर रीराइट में बदल जाते हैं।
उद्देश्य इतना विवरण देने का होना चाहिए कि कोई भी विफलता को पहले असली त्रुटि से लेकर अंत तक फ़ॉलो कर सके, और फिर सबसे कम बदलाव करे।
अपनी संदेश में ये कॉपी करें (जहाँ संभव हो ठीक वैसा ही):
go test ./..., npm test, flutter test, golangci-lint run).सीधी शर्तें सरल शब्दों में जोड़ें। अगर आप एक छोटा फिक्स चाहते हैं, तो कहें: कोई रिफ़ैक्टर नहीं, व्यवहार परिवर्तन नहीं जब तक ज़रूरी न हो, पैच को सिर्फ फेलिंग एरिया तक सीमित रखें।
एक साधारण उदाहरण: CI एक lint स्टेप पर फेल होता है dependency bump के बाद। पहले की चेतावनियों से शुरू करके lint आउटपुट पेस्ट करें, CI ने कौन‑सा कमांड चलाया यह शामिल करें, और बताएं केवल एक पैकेज वर्ज़न बदला था। इतना ही अक्सर एक एक‑लाइन कॉन्फ़िग ट्वीक या छोटा कोड चेंज सुझाने के लिए काफी होता है, बजाय पूरे रिपो को रीफ़ार्मेट करने के।
यदि आप कुछ कॉपी‑पेस्ट करने योग्य चाहते हैं, तो यह स्ट्रक्चर आमतौर पर काफी होता है:
CI command:
Failing output (full):
Recent changes:
Constraints (smallest fix, no refactor):
Flaky? (runs attached):
जब कोई मॉडल CI ब्रेक पर चूकता है, तो अक्सर फैसला यह होता है कि आपका प्रॉम्प्ट उसे अनुमान लगाने देता है। आपकी ज़िम्मेदारी है कि आप उसे अपने काम के प्रमाण दिखाकर और उस सबसे छोटे बदलाव के लिए प्रतिबद्ध कराएं जो जॉब को पास कर देगा।
सबूत और एक छोटा प्लान माँगें। एक अच्छा प्रॉम्प्ट पाँच चीज़ें ज़ोर देकर मांगता है:
अनिश्चितता ठीक है। छुपी हुई अनिश्चितता समय बर्बाद करती है।
अपने CI प्रश्न के शीर्ष पर यह पेस्ट करें:
Use ONLY the evidence in the CI output below.
1) Quote the exact failing lines you are using.
2) Give ONE sentence: the most likely cause.
3) Propose the smallest fix: 1-3 edits, with file paths.
4) Do NOT do formatting/renames/refactors or "cleanup".
5) List uncertainties + the one extra detail that would confirm the diagnosis.
यदि लॉग कहता है "expected 200, got 500" और स्टैक ट्रेस user_service.go:142 में जाता है, तो यह स्ट्रक्चर प्रतिक्रिया को उस फ़ंक्शन और एक छोटे गार्ड या एरर हैंडलिंग परिवर्तन की ओर धकेलेगा, न कि एंडपॉइंट के री‑डिज़ाइन की ओर।
सबसे तेज़ जीतें उन प्रॉम्प्ट्स से आती हैं जो लॉग को कोट करने के लिए मजबूर करती हैं, सीमाओं के भीतर रहती हैं, और जब कुछ कमी हो तो रुक जाती हैं।
You are helping me fix a CI failure.
Repo context (short):
- Language/framework:
- Test/build command that failed: <PASTE THE EXACT COMMAND>
- CI environment (OS, Node/Go/Python versions, etc.):
Failing output (verbatim, include the first error and 20 lines above it):
<PASTE LOG>
Constraints:
- Propose the smallest possible code change that makes CI pass.
- Do NOT rewrite/refactor unrelated code.
- Do NOT touch files you do not need for the fix.
- If behavior changes, make it explicit and justify why it is correct.
Stop rule (no guessing):
- If the log is incomplete or you need more info (missing stack trace, config, versions, failing test name), STOP and ask only the minimum questions needed.
Your response format (follow exactly):
1) Evidence: Quote the exact log lines that matter.
2) Hypothesis: Explain the most likely cause in 2-4 sentences.
3) Smallest fix: Describe the minimal change and why it addresses the evidence.
4) Patch: Provide a unified diff.
5) Follow-up: Tell me the exact command(s) to rerun locally to confirm.
Then, write ONE regression test (or tweak an existing one) that would fail before this fix and pass after it, to prevent the same failure class.
- Keep the test focused. No broad test suites.
- If a test is not feasible, explain why and propose the next-best guardrail (lint rule, type check, assertion).
दो बातें जो बैक‑एंड‑अवश्यकता कम करती हैं:
समय खोने का सबसे तेज़ तरीका यह स्वीकार करना है कि "क्लीनअप" चेंज सेट को मंज़ूर कर लें जो एक साथ पाँच चीजें बदलता है। पहले से परिभाषित करें कि "न्यूनतम" क्या है: वह सबसे छोटा डिफ़ जिसे फेलिंग जॉब पास करने के लिए चाहिए, सबसे कम रिस्क और सबसे तेज़ सत्यापन का तरीका।
एक सरल नियम सहायक होता है: पहले लक्षण को ठीक करें, फिर तय करें कि क्या व्यापक रिफ़ैक्टर वर्थ है। अगर लॉग एक फ़ाइल, एक फ़ंक्शन, एक मिसिंग इम्पोर्ट, या एक एज‑केस की ओर इशारा करता है, तो वहीं लक्ष्य रखें। "अभी यहाँ हैं" वाले एडिट्स से बचें।
अगर सच में विकल्प चाहिए हों, तो दो ही माँगें: "सबसे सुरक्षित न्यूनतम फिक्स" बनाम "सबसे तेज़ न्यूनतम फिक्स"। आप ट्रेडऑफ़ चाहते हैं, न कि मेन्यू।
स्थानीय सत्यापन की मांग भी करें जो CI से मेल खाती हो: वही कमांड जो पाइपलाइन चलाती है (या सबसे नज़दीकी समकक्ष), ताकि आप मिनटों में पुष्टि कर सकें:
# run the same unit test target CI runs
make test
# or the exact script used in CI
npm test
अगर उत्तर बड़ा बदलाव सुझाए, तो पीछे हटें और कहें: "सबसे छोटा पैच दिखाइए जो फेलिंग assertion को ठीक करता है, बिना अनावश्यक फॉर्मैटिंग या रीनैम्स के।"
एक फिक्स बिना टेस्ट के एक सट्टा है कि वही समस्या फिर ना आए। हमेशा एक फॉलो‑अप टेस्ट माँगें जो फिक्स से पहले फेल करता हो और बाद में पास हो।
"अच्छा" दिखने का स्पेसिफिक वर्णन दें:
एक उपयोगी पैटर्न चार बातें माँगता है: टेस्ट कहाँ रखें, क्या नाम दें, कौन‑सा व्यवहार कवर करे, और 2-3 वाक्यों में बताएं क्यों यह भविष्य में समान बग पकड़ लेगा।
कॉपी‑रेडी ऐड‑ऑन:
उदाहरण: CI में एक पैनिक दिखता है जब API हैंडलर खाली string ID प्राप्त करता है। ऐसे में पूछें कि invalid IDs (empty, whitespace, wrong format) के लिए एक टेस्ट लिखें। सबसे छोटा फिक्स एक गार्ड क्लॉज़ हो सकता है जो 400 रिटर्न करे। फॉलो‑अप टेस्ट कई invalid inputs पर आश्यर्ता करेगा ताकि कोई भविष्य का रिफ़ैक्टर पार्सिंग fallback हटा दे तो CI तुरंत फेल हो।
पहली असली त्रुटि और उसके ~20–40 लाइनों का लॉग पेस्ट करें। साथ में सटीक फेलिंग कमांड और जरूरी एन्वायरनमेंट डिटेल्स (OS, रनटाइम वर्ज़न, महत्वपूर्ण फ्लैग्स) दें।
फिर कहें कि वह विफलता को साधारण अंग्रेज़ी में फिर से बताए और लॉग की उन लाइनों को इंगित करे जो इसे साबित करती हैं। अगर वह लॉग को कोट नहीं कर पाया, तो उसने वास्तव में उसे नहीं पढ़ा।
वह सबसे छोटा संभव कोड बदलाव प्रस्तावित करे जो फेलिंग कमांड को पास कराए। रिफ़ैक्टर्स पर दबाव डालें। किसी भी चीज़ को लागू करने से पहले, उससे यह सूची माँगें:
पैच लागू करें और वही फेलिंग कमांड लोकली चलाएँ (या उसी CI जॉब में अगर वही आपका विकल्प है)। अगर वह अभी भी फेल करता है, तो केवल नया फेलिंग आउटपुट पेस्ट करें और प्रक्रिया दोहराएँ। संदर्भ छोटा रखने से उत्तर फ़ोकस्ड रहते हैं।
एक बार ग्रीन हो जाने पर एक फॉलो‑अप टेस्ट जोड़ें जो पहले फेल और अब पास हो। लक्षित रखें: एक टेस्ट, एक कारण।
नई टेस्ट के साथ वही कमांड फिर से चलाएँ यह सुनिश्चित करने के लिए कि आपने त्रुटि सिर्फ़ साइलेंस नहीं की है।
छोटा commit message और PR description माँगें जिसमें क्या फेल हुआ, क्या बदला, आपने कैसे सत्यापित किया, और कौन‑सा टेस्ट रिपीट रोकता है। रिव्यूअर तेज़ी से आगे बढ़ते हैं जब कारण स्पष्ट लिखा हो।
एक आम फेल: लोकल पर सब सही था, फिर एक छोटा बदलाव CI रनों पर टेस्ट फेल करवा देता है। यहाँ एक साधारण Go API का उदाहरण है जहाँ handler अब date-only मान (2026-01-09) स्वीकार करने लगा लेकिन कोड अभी भी केवल RFC3339 timestamps पार्स करता है।
यह वही स्निपेट है जिसे पेस्ट करना चाहिए (संक्षिप्त रखें, पर त्रुटि लाइन शामिल करें):
--- FAIL: TestCreateInvoice_DueDate (0.01s)
invoice_test.go:48: expected 201, got 400
invoice_test.go:49: response: {"error":"invalid due_date: parsing time \"2026-01-09\" as \"2006-01-02T15:04:05Z07:00\": cannot parse \"\" as \"T\""}
FAIL
exit status 1
FAIL app/api 0.243s
अब एक प्रॉम्प्ट का उपयोग करें जो सबूत, न्यूनतम फिक्स और एक टेस्ट मजबूर करे:
You are fixing a CI failure. You MUST use the log to justify every claim.
Context:
- Language: Go
- Failing test: TestCreateInvoice_DueDate
- Log snippet:
<PASTE LOG>
Task:
1) Quote the exact failing line(s) from the log and explain the root cause in 1-2 sentences.
2) Propose the smallest possible code change (one function, one file) to accept both RFC3339 and YYYY-MM-DD.
3) Show the exact patch.
4) Add one regression test that fails before the fix and passes after.
Return your answer with headings: Evidence, Minimal Fix, Patch, Regression Test.
एक अच्छा उत्तर पार्सिंग लेआउट mismatch की ओर इशारा करेगा, फिर parseDueDate जैसा एक फ़ंक्शन में छोटा बदलाव करेगा जो पहले RFC3339 आज़माए और fallback में 2006-01-02 को ट्राई करे। कोई रिफ़ैक्टर नहीं और कोई नया पैकेज नहीं।
रिग्रेशन टेस्ट गार्डरेल है: भेजें due_date: "2026-01-09" और अपेक्षा करें 201। अगर कोई बाद में fallback हटा देता है तो CI फिर उसी त्रुटि से फेल हो जाएगा।
सबसे तेज़ तरीका एक घंटा खोने का यह है कि आप समस्या का कट‑डाउन व्यू दें। CI लॉग शोर से भरे होते हैं, पर उपयोगी हिस्सा अक्सर आख़िरी त्रुटि से ~20 लाइनों ऊपर होता है।
एक जाल केवल आख़िरी लाल लाइन चिपकाना है (जैसे "exit 1") जबकि असली कारण पहले कहीं और छिपा होता है (missing env var, failing snapshot, या पहली टेस्ट जो क्रैश हुई)। सुधार: पहली असली त्रुटि और फेलिंग कमांड शामिल करें।
एक और समय‑खपत वाली गलती मॉडल को बीच‑रास्ते "tidy up" करने देना है। अतिरिक्त फॉर्मैटिंग, dependency bumps, या रिफ़ैक्टर बड़े बदलाव हैं जो रिव्यू को कठिन बनाते हैं और कुछ और तोड़ भी सकते हैं। समाधान: स्कोप को सबसे छोटे कोड बदल तक लॉक करें और unrelated बदलाव रिजेक्ट करें।
देखने योग्य पैटर्न:
अगर आपको फ्लेकिनेस शक है, retries से काम न चलाएँ—रैंडमनेस हटाएँ (fixed time, seeded RNG, isolated temp dirs) ताकि सिग्नल साफ़ हो।
पुश करने से पहले एक छोटा सैनीटी पास करें। उद्देश्य यह सुनिश्चित करना है कि परिवर्तन वास्तविक, न्यूनतम और दोहराने योग्य है, न कि केवल एक भाग्यशाली रन।
अंत में, मूल फेलिंग जॉब से थोड़ा व्यापक सेट चलाएँ (उदा., lint + unit tests) ताकि कोई ऐसा फिक्स न आए जो ओर targets तोड़ दे।
अगर आप चाहते हैं कि यह हफ्तों में समय बचाए, तो अपने प्रॉम्प्ट और प्रतिक्रिया फ़ॉर्मेट को टीम प्रक्रिया की तरह रखें। लक्ष्य: दोहराने योग्य इनपुट, दोहराने योग्य आउटपुट, और कम "मिस्ट्री फिक्स" जो कुछ और तोड़ दें।
अपने सर्वश्रेष्ठ प्रॉम्प्ट को एक रेपो स्निपेट के रूप में सेव करें और टीम चैट में पिन करें। जब सभी उसी फॉर्मेट का उपयोग करें, तो रिव्यूअर तेज़ी से आगे बढ़ते हैं क्योंकि उन्हें पता होता है कहाँ देखना है।
एक हल्का‑वेट हैबिट लूप जो ज़्यादातर टीमों में काम करता है:
अगर आप चैट‑फर्स्ट वर्कफ़्लो पसंद करते हैं, तो वही फिक्स‑एंड‑टेस्ट लूप Koder.ai के अंदर चला सकते हैं, प्रयोग करते समय स्नैपशॉट्स लें, और जब तैयार हों तो सोर्स को एक्सपोर्ट कर के सामान्य रिपो में मर्ज कर दें।
पहली असली त्रुटि से शुरू करें, अंतिम exit 1 से नहीं।
AI को साबित करने को कहें कि उसने लॉग पढ़ा है।
किसी प्रतिबंध का उपयोग करें जैसे:
डिफ़ॉल्ट रूप से उस सबसे छोटे पैच को चुनें जो विफल कदम को सफल बनाये।
यह आमतौर पर होता है:
“क्लीनअप” बदलावों से बचें जब तक CI ग्रीन न हो।
विफलता को पुन: उत्पन्न करने के लिए पर्याप्त संदर्भ पेस्ट करें, सिर्फ आख़िरी लाल लाइन नहीं।
शामिल करें:
go test ./..., npm test, , आदि)।हां—प्रतिबंध साफ़ शब्दों में बताएं और दोहराएँ।
उदाहरण प्रतिबंध:
यह प्रतिक्रिया को फ़ोकस्ड और समीक्षा योग्य रखता है।
पहली असली त्रुटि को पहले ठीक करें।
संदेह हो तो मॉडल से लॉग में पहला फेलिंग स्टेप पहचानने के लिए कहें और उसी पर टिके रहें।
फ्लेकिनेस को retries से नहीं, बल्कि randomness हटाकर ठीक करें।
सामान्य स्थिरीकरण:
एक बार डिटरमिनिस्टिक हो जाने पर सबसे छोटा फिक्स स्पष्ट हो जाता है।
CI ने जो कमांड चलाया, वही लोकली चलाएँ:
यदि लोकल रिप्रो कठिन है, तो रिपो के अंदर एक न्यूनतम repro पूछें (एक सिंगल टेस्ट/टार्गेट) जो वही त्रुटि ट्रिगर करे।
एक फोकस्ड रिग्रेशन टेस्ट लिखें जो फिक्स से पहले फेल और फिक्स के बाद पास हो।
अच्छे लक्ष्य:
यदि यह लिंट/बिल्ड फेल है, तो समान “टेस्ट” लिंट नियम कड़ा करने या चेक जोड़ने जैसा होगा।
स्नैपशॉट/रोलबैक का प्रयोग करें ताकि प्रयोग reversible रहें।
एक व्यावहारिक लूप:
Koder.ai में स्नैपशॉट्स होने पर आप तेज़ी से प्रयोग कर सकते हैं बिना एक्सपेरिमेंटल एडिट्स को अंतिम पैच में मिला दिए।
flutter test