هل يمكن استخدام دليل المكونات الإضافية المحلي لتحميله في Discourse بدلاً من الارتباط بمستودع GitHub بعيد من app.yml؟ إذا كان الأمر كذلك، فكيف؟
لقد جربت طريقتين اعتقدت أنهما يجب أن تعملان:
استنسخت discourse-math من GitHub في /var/discourse/plugins/discourse-math. لم يذكر launcher rebuild شيئًا عن discourse-math ولا يوجد discourse-math في حاوية Docker، ولا في الواجهة الرسومية. لذا أعتقد أن مجلد plugins يتم تجاهله؟
حاولت أيضًا الاستنساخ في دليل مختلف خارج /var/discourse وربطه رمزيًا بـ /var/discourse/plugins/discourse-math … نفس النتيجة.
استنسخت مستودع GitHub في /var/discourse-math.git وقمت بتحرير app.yml الخاص بي ليقول - git clone file:////var/discourse-math.git ولكن بعد ذلك اشتكى launcher rebuildfatal: '/var/discourse-math.git' does not appear to be a git repository … يُفترض أن المنفذ يقوم بتشغيل هذا في حاوية Docker بالفعل؟ تشغيل cd /tmp \u0026\u0026 git clone file:////var/discourse-math.git يدويًا يعمل بشكل جيد.
لذلك، إذا كنت تقوم بتشغيل حاوية discourse docker الخاصة بك من داخل ~/discourse، يمكنك استنساخ الإضافات الخاصة بك أو إنشاء ارتباط رمزي إلى ~discourse/plugins محليًا.
حسنًا، نعم، كنت على علم بتثبيت المطور، ولكن لدي تثبيت Docker قياسي (أي تثبيت غير مطور)، لذا أعتقد أن سؤالي لا يزال قائمًا: هل يمكنني تحميل إضافة من دليل محلي أو فقط عن بُعد من GitHub عبر app.yml؟
ملاحظة: أنا على دراية تامة بأن التدفق “الصحيح” هو إجراء تثبيت مطور واللعب هناك. أردت طريقة سريعة وغير رسمية لتعديل واختبار إضافة بدلاً من المرور بكل آلام تثبيت وإعداد المطور.
سيقوم تثبيت الإنتاج بنسخ المكونات الإضافية إلى الحاوية، لذا فهذا غير مناسب لتطوير المكونات الإضافية المحلية، حيث ستحتاج إلى تحميل تغييراتك إلى GitHub لهذا سير العمل.
اقتراحي هو التخلي عن هذا الإعداد واستخدام أحد خياري التطوير الرئيسيين، دوكر أو غير دوكر.
فقط للتأكد من أنني فهمتك بشكل صحيح: أنت تشير إلى استنساخ الإضافات من GitHub البعيد، وغير قادر على الاستنساخ من دليل محلي، حتى عبر GitHub file:///? أفترض أن launcher.sh في تلك المرحلة يعمل في حاوية وليس في المضيف، أي أنه يستنسخ من GitHub أثناء وجوده في الحاوية، بدلاً من الاستنساخ من المضيف إلى المجلد الذي تم تحميله في المضيف… مما سيسمح لي بعمل git clone لـ file:///…
إذا كنت ترغب في تحويل تثبيت الإنتاج إلى “فرانكنشتاين” قادر على الوصول إلى الدلائل المحلية المثبتة، فستحتاج إلى تغيير نصوص البناء لمنحه هذا الوصول. ستحتاج إلى تحمل مسؤولية دعم هذه التخصيصات بنفسك.
في رأيي المتواضع، أنت فقط تخلق لنفسك عملاً وهشاشة.
تثبيت Docker Dev مصمم بدقة لمنحك حلاً منخفض الصيانة لتطوير المكونات الإضافية المحلية بكفاءة، يرجى التفكير في استخدامه.
أعلم، وأنت على حق بالطبع. كان ذلك لتغيير بسيط للاختبار في ملف جافاسكريبت خاص بإضافة. قمت بتحريره مباشرة في الحاوية (/var/www/discourse/public/assets/plugins/discourse-math-.js) ولكن لسبب ما، لم تنعكس تعديلاتي في المتصفح - يرى المتصفح الملف القديم، على الرغم من تنظيف ذاكرة التخزين المؤقت، ربما لأن ملفات جافاسكريبت الخاصة بالإضافة يتم تخزينها مؤقتًا بواسطة nginx المضمن أو شيء من هذا القبيل (؟).
سأكون ممتنًا للحصول على نصيحة حول طريقة لتحرير ملف جافاسكريبت حالي داخل الحاوية (مهما بدا ذلك غريبًا) وجعله مرئيًا للمتصفح.
ربما انتهى بي الأمر بالفعل في منطقة “لم يكن لدي وقت لكتابة رسالة قصيرة” … لم يكن لدي وقت للسير في المسار الصحيح للتثبيت التطويري ولم أتوقع أن يكون تعديل ملف جافاسكريبت داخل الحاوية بهذه الصعوبة (وقت قليل لقراءة كيفية تخزين Discourse لملفات جافاسكريبت الخاصة بالإضافات لجعل تغييراتي مرئية في المتصفح)، وما إلى ذلك، إلخ.
يتم تحميل مكونات السمة في النهاية، على ما أعتقد، لذا ستحل محل المكون الإضافي.
خيار جيد آخر هو مجرد إنشاء نسخة من المكون الإضافي، واستنساخها محليًا لتعديلها واختبارها باستخدام تثبيت محلي dev (؛)). بمجرد الرضا، قم بتثبيتها ودفعها إلى نسختك واستخدم النسخة للإنتاج.
ومع ذلك، فإن حل مكون السمة له ميزة أنه لا يتعين عليك صيانة نسخة قد تصبح مؤلمة مع تطور المكون الإضافي الأصلي.
لست متأكدًا من أن مكون “Theme” يساعد عندما أحتاج إلى تعديل ملف مثل هذا… هذا الملف (إلى جانب ملفات أخرى)، كما أفهم، يمر عبر “mapper” وما إلى ذلك، لإنتاج ملف /var/www/discourse/public/applets/plugins/discourse-math-<id>.js الخاص بالحاوية الذي يقوم المتصفح بتحميله. أنا فقط بحاجة إلى تغيير الأخير، لكن المتصفح لا يزال يرى الملف القديم، كما لو كان هناك تخزين مؤقت من جانب الخادم.
التثبيت المحلي للتطوير يستهلك الوقت والجهد ولكنه قد يكون حلاً إذا فشل كل شيء آخر. لم أتوقع أن يكون التعديل غير النظيف لملف JavaScript الخاص بالمكون الإضافي مؤلمًا لهذه الدرجة. ما زلت لا أفهم لماذا لا تظهر تعديلاتي المباشرة في المتصفح، ما لم يكن هناك تخزين مؤقت من جانب الخادم في nginx الخاص بالحاوية (لا أعرف السبب نظرًا لأنه ملف JavaScript).
على أي حال، انتهى الوقت المتاح لي اليوم للبحث في هذا الأمر :(. شكرًا على المساعدة بغض النظر!
تطورت أدوات التطوير لهذا الغرض بالضبط، لذا إذا استطعت، فاستخدمها. يجب أن يستغرق إعداد بيئة Docker للتطوير دقائق، وليس ساعات، ويجب أن تحتاج إليها مرة واحدة فقط، ثم تكون مفيدة لجميع أنواع الأغراض لاحقًا. لا تغرِ نفسك باستخدام التثبيت الإنتاجي محليًا فقط لأنك معتاد عليه! إنه ببساطة غير مُعد لهذا الغرض.
نادني غبي ولكن كيف أغير المنفذ الافتراضي 3000 إلى شيء آخر؟ يفشل d/boot-dev --init لأنني أستخدم هذا المنفذ لشيء آخر. لقد جربت -e UNICORN_PORT=4200. الأدلة التي رأيتها لا تقول شيئًا عن المنفذ. يبدو أن ملف thin.yml في config/cloud/cloud66/files يتم تجاهله أيضًا
3000 هو منفذ خادم Ruby و 4200 هو منفذ Ember. يجب تشغيل كلتا العمليتين. يمكنك الوصول إلى الموقع في المتصفح عبر 4200. هل من الأفضل مناقشة تثبيت Docker للمطورين في موضوع Docker للمطورين؟
حسنًا، يفشل الأمر d/boot_dev --init (خطأ في بدء تشغيل وكيل المستخدم: الاستماع إلى tcp 127.0.0.1:3000: ربط: العنوان قيد الاستخدام بالفعل.). ربما سأتعمق في هذا لاحقًا. شكراً لوقتك. أتمنى لو كانت هذه الأشياء موثقة بشكل أفضل.
إنه ببساطة غير مُعد لهذا الغرض.