هاها، كما قلت، أنا أستخدمه لشيء آخر، لا يمكنني فقط إيقافه. بالتأكيد لا ينبغي أن يكون من الصعب تغيير المنفذ (كلمات أخيرة مشهورة على ما يبدو)
اقترح أن تسأل ذلك في الموضوع المرتبط، من خلال نظرتي السريعة على هذا النص البرمجي، يبدو أنه مكتوب بشكل ثابت، ولكن قد أكون مخطئًا، قد يكون النص البرمجي مبنيًا.
لاحظت أيضًا الأشياء المكتوبة بشكل ثابت، ومع ذلك توجد إشارات إلى تكوين منفذ في ملفات yml بالإضافة إلى متغيرات البيئة. سأتخلى عن هذا في الوقت الحالي. لقد استثمرت وقتًا طويلاً بالفعل فيما أردت اختباره.
تم تشغيل جهاز افتراضي بنظام Ubuntu 22.04 جديد. فشل تثبيت التطوير: Install Discourse for development using Docker - #213 by nordize
ليس يومي … ولكن بالتأكيد ليس دقائق أيضًا (بدون تورية). شكرًا لوقتك، وأعتذر لأنك اضطررت لإهداره أيضًا.
@merefield سؤال سريع: هل هناك طريقة أسرع للحصول على تحديثات كود الإضافات في الحاوية بدلاً من تنفيذ d/shutdown_dev; d/boot_dev التي تستغرق وقتًا طويلاً وتنزيل كمية كبيرة من البيانات عند سحب صور docker؟ يبدو أن القيام بذلك في كل مرة أغير فيها سطرًا من التعليمات البرمجية للاختبار في المتصفح هو أمر مبالغ فيه حتى بالنسبة لبيئة تعمل بنظام docker
إعادة تشغيل خادم rails باستخدام d/rails s لا يعرض تغييرات كود الإضافة الخاصة بي.
هذا يجب أن يكون ضروريًا فقط إذا قمت بإزالة أو إضافة مكون إضافي، وليس إذا قمت بتغيير سطر من التعليمات البرمجية.
إذا كان هذا السطر Ruby أو CSS، فسيتم تحميل التعليمات البرمجية الجديدة بسرعة. إذا كان Ruby، فيجب أن ترى وحيد القرن يعاد تشغيله في الطرفية.
إذا كان JavaScript، فما عليك سوى تحديث المتصفح.
كان يجب أن أذكر أن المكون الإضافي الخاص بي موجود في رابط رمزي، وأن أي تغييرات لا تنعكس إلا إذا قمت بتشغيل d/shutdown_dev; d/boot_dev (هذا مذكور أيضًا في الدليل)، ولكني كنت آمل أن تكون هناك طريقة بديلة عبر Docker نفسه نظرًا لأن هذه يجب أن تكون مجرد ملفات معينة. قد أسأل في الموضوع الآخر أو أرى ما إذا كان بإمكاني تعديله كحل بديل (أو عدم استخدام الروابط الرمزية).
هذا لا يبدو صحيحًا بالنسبة لي. عملية الخادم ببساطة تعيد التشغيل كما تفعل في تثبيت غير دوكر. يجب ألا تحدث الروابط الرمزية فرقًا وهي الطريقة المناسبة للعمل. ليس لدي أي فكرة لماذا لا يتصرف جهازك بهذه الطريقة …
حسنًا، لا تتردد في تجربتها. لم أكن لأقوم بالنشر لو كان إعادة تشغيل Rails و Ember كافيًا. كما كنت أقول، الدليل يشير أيضًا إلى هذا.
وفقًا للدليل، يجب أن تكون أوامر إعادة التشغيل هذه ضرورية فقط إذا قمت بتغيير مجموعة المكونات الإضافية (على سبيل المثال، عن طريق إزالة أو إضافة رابط رمزي صالح). بخلاف ذلك، يجب أن يكتشف Rails تغييرات التعليمات البرمجية ويعيد تشغيل عملياته. قد يكون من الممكن تعطيل هذا السلوك في التكوين، ولكن يجب أن يكون هذا هو الوضع الافتراضي.
إليك مثال على إعادة التشغيل الآلية، وإن كان ذلك على تثبيت تطوير غير docker، ولكن يجب أن يكون السلوك مشابهًا:
[DEV]: تم تحرير الملفات التي لم يتم تحميلها تلقائيًا. جارٍ إعادة تشغيل الخادم...
- plugins/discourse-multilingual/extensions/post.rb
إعادة تشغيل UNICORN
I, [2022-06-15T13:25:29.082415 #227981] INFO -- : تم إعادة #\u003cProcess::Status: pid 228047 exit 0\u003e worker=0
I, [2022-06-15T13:25:29.082642 #227981] INFO -- : تم إعادة #\u003cProcess::Status: pid 228048 exit 0\u003e worker=1
I, [2022-06-15T13:25:29.082788 #227981] INFO -- : تم إعادة #\u003cProcess::Status: pid 228049 exit 0\u003e worker=2
I, [2022-06-15T13:25:29.082877 #227981] INFO -- : اكتمل المشرف
I, [2022-06-15T13:25:29.947587 #228661] INFO -- : تحديث قائمة Gem
تم تلقي إشارة TERM
جارٍ إيقاف التشغيل
جارٍ إنهاء الخيوط الهادئة
ينتهي المجدول...
توقف للسماح بانتهاء المهام...
وداعًا!
بدء مراقب تغيير CSS
I, [2022-06-15T13:25:38.326511 #228661] INFO -- : الاستماع على addr=0.0.0.0:3000 fd=25
لقد قمت بتحرير الملف post.rb وضغطت على حفظ، والباقي تم تلقائيًا.
آسف، ليس لدي وصول إلى جهاز التطوير الخاص بي المستند إلى docker حيث أنا حاليًا للتأكد من أن هذا هو الحال في تثبيت docker أيضًا، ولكن أتذكر أنه كذلك، ما لم يتغير شيء ما.
أنا لا أختلق ذلك، كما تعلم
ولا يمكنني فعل الكثير مع إخباري بأنه يجب أن يعمل
لقد اتبعت هذا الدليل حرفيًا في تثبيت جديد لآلة افتراضية مع Ubuntu 22.04.
- ربط المكون الإضافي في المجلد الفرعي discourse/plugins/ وتغيير كود JavaScript في المكون الإضافي لا يُرى إلا إذا قمت بتشغيل d/shutdown_dev؛ d/boot_dev، على الرغم من إعادة تشغيل d/rails s و d/ember-cli
- نسخ المكون الإضافي إلى المجلد الفرعي discourse/plugins/ وتغيير كود JavaScript في المكون الإضافي يُرى دون تشغيل d/shutdown_dev؛ d/boot_dev ولكن فقط إعادة تشغيل d/rails s و d/ember-cli
لا تتردد في تجربة ما سبق. المكون الإضافي المعني هو discourse-math، وتغيير الكود في assets/initializers/javascript/*.js (مع الأخذ في الاعتبار أن هذه الملفات المحددة للمكون الإضافي يتم تحميلها جانبيًا، ولا يتم استدعاؤها مباشرة بواسطة المتصفح؛ لست متأكدًا مما إذا كان ذلك يحدث فرقًا، لم أتعمق كثيرًا بعد في كيفية عمل Discourse داخليًا).
ملاحظة: أعرف أنني بحاجة إلى تحديث المتصفح (تجاوز ذاكرة التخزين المؤقت) … امنحني بعض التقدير.
من مصدر موثوق كما يقال:
إذًا، المشكلة قد تكون محلية لديك، أو هناك تراجع في البناء الحالي، ولكن هذا الأخير يبدو غير مرجح.
أنا أستسلم، لقد فزت. إذا جربتها بنفسك في أي وقت، فأخبرني.
أنا بالتأكيد لا أحاول “الفوز”، ولكن يجب أن نصل إلى مستوى أساسي من الفهم:
- من المفترض أن يُعاد تشغيله تلقائيًا عند إجراء تغييرات في كود الواجهة الخلفية.
d/shutdown_dev; d/boot_devيجب أن يكون ضروريًا فقط عند تغيير مجموعة المكونات الإضافية وليس مجرد أسطر فردية من التعليمات البرمجية.
يجب أن يقلل هذا من المكان الذي تحتاج إلى البحث فيه لإصلاح الأشياء.
لقد قمت للتو بسحب التغييرات باستخدام git وجربت تغييرًا، فقد أعيد تشغيله، لذا فهي ليست مشكلة في البناء.
الجزء الأكثر غرابة بالنسبة لي هو أنه نظرًا لأنه إعداد docker، فمن الصعب فعليًا تجاوز السلوك المعبأ عن غير قصد، لذلك يجب أن يكون أكثر موثوقية.
سأجرب هذا على بناء docker الخاص بي عندما أعود إلى المنزل.
أقدر أن هذا محبط ومزعج كسير عمل في الوقت الحالي، ومن المؤكد أنه سيزعجني ويحبطني.
إذا قمت بمسح ذاكرة التخزين المؤقت بالكامل، فلست متأكدًا مما أقترحه في هذه المرحلة.
لاحظ أن المبادرات تعمل مرة واحدة فقط عند فتح الصفحة لأول مرة. لذا فإن إعادة تشغيل خادم العمليات لا طائل من ورائها (ويغطي فقط كود الواجهة الخلفية).
أقوم بتشغيل أدوات التطوير مع تعطيل ذاكرة التخزين المؤقت كلما قمت بتطوير تطبيقات الويب. أنا جديد فقط على كود وأدوات Discourse، وليس على (تطوير) الويب. لقد طرحت سؤالاً في سلسلة الأدلة أيضًا. في الوقت الحالي، قمت فقط بنسخ دليل المكونات الإضافية تحت discourse/plugins/ لتجنب الألم.
سأجرب شيئًا مشابهًا لاحقًا اليوم وسأبلغكم بالنتائج.
على حد علمي من استدعاءات المتصفح، يتم تحميل كود JS من مُهيئ JS بشكل جانبي عبر discourse-math.js، عبر eval() (عند كل فتح للصفحة)، مما يشير بوضوح إلى أن بعض المكونات من جانب الخادم تعالج وتُخزن مؤقتًا كود JS هذا من المُهيئ (وهو الذي أقوم بتغييره)، وبالتالي فإن ذلك المُخزن المؤقت المحدد من جانب الخادم هو الذي يحتاج إلى تشغيله لإعادة التخزين المؤقت … وهو ما لا يحدث إذا كان المكون الإضافي مرتبطًا رمزيًا ولكنه يحدث عند نسخه.
أنا لست على دراية (ولم أرغب في التعرف عليه في هذا الوقت بسبب ضيق الوقت) بسلسلة أدوات Discourse … ومن هنا جاءت هندستي العكسية وأسئلتي.
تطوير غير دوكر:
جربت هذا للتو في مُهيئ، لا حاجة لإعادة تشغيل أي عملية، فقط تحديث المتصفح التقط التغيير في كود الجافاسكريبت … كان هذا غير دوكر … سأجرب ذلك لاحقًا
بعد بعض الوقت…
تطوير دوكر:
حسنًا، لقد وصلت الآن إلى جهاز الكمبيوتر الخاص بي وجربت حل دوكر الذي قمت فيه بتثبيت جديد تمامًا، وأرى نفس السلوك: تعديلات على المُهيئ تعمل بالنسبة لي مع ترك الخوادم قيد التشغيل وببساطة حفظ الملف وتحديث المتصفح، لا حاجة لإعادة بناء الحاوية.
إذًا نفس السلوك
(استخدمت إضافة Discourse Locations كمثال.)
هل أنت متأكد من عدم وجود خطأ في المُهيئ الخاص بك؟
نظرًا لأنه يعمل بعد إعادة التشغيل، نعم، أنا متأكد. لضمان إمكانية تكرار المشكلة بنسبة 100%، يمكنك تجربة المكون الإضافي المحدد الذي ذكرته، وتمكينه في واجهة المستخدم الرسومية واختيار خيار Katex في واجهة المستخدم الرسومية، ثم تعديل ملف تهيئة JavaScript الذي ذكرته، ثم إنشاء منشور يحتوي على كود Latex بداخله؛ قد يكون هذا المكون الإضافي مميزًا، وربما يقوم بتحميل مُهيئ JavaScript الخاص به عند الحاجة فقط إذا كان المنشور يحتوي على كود Latex (هذا ما سأفعله إذا صممت Discourse) … لكنني لا أتوقع منك إضاعة الوقت في هذه المشكلة، ولست أحاول إقناعك بأنني لا أختلق الأمور ![]()
نقطة جيدة.
هذا غريب جداً جداً.
اقتراحي الوحيد في الوقت الحالي هو التبديل إلى تثبيت غير دوكر (والذي يستغرق وقتاً أطول للإعداد للأسف
) ومعرفة كيف يسير الأمر؟
سيكون من الجيد الحصول على بعض المدخلات من الفريق حول ما قد يحدث بشكل خاطئ بالنسبة لك. ومع ذلك، فإن حل دوكر سيقلل بالتأكيد من فرص السلوك المختلف هنا حيث أنه محتوى ومستقل ![]()