مرحباً،
نحن بحاجة إلى استخدام هذه الميزة/وظيفة البريد الإلكتروني الجديدة:
نظرًا لأنه لم يتم دمجه (نفترض أنه سيتم دمجه يومًا ما)، فما هي الطريقة الموصى بها لتشغيل إنتاج Discourse وتضمين طلب سحب قيد المراجعة؟
أفترض أنه يتعين علينا تجنب/عدم تحديث Discourse للتحديثات العادية، ولكن هذا ربما يبسط النهج بشكل مفرط.
نقدر أي توجيه حول كيفية عمل الآخرين في هذا السيناريو.
أولاً: لا أعرف.
لكن أعتقد أن هذا قد ينجح:
cd /var/discourse
./launcher enter app
cd /var/www/discourse
su - discourse -c 'git fetch origin pull/<pr_number>/head:<local_branch_name>'
su - discourse -c 'git switch <local_branch_name>'
sv restart unicorn
إذا نجح ذلك، فيمكنك إضافة أشياء إلى app.yml الخاص بك لجعله يفعل ذلك أثناء البناء. أو ربما سيتم دمجه قريبًا ويمكنك الانتظار.
إذا جعل ذلك الأمور أسوأ، يمكنك القيام بـ
./launcher destroy app;./launcher start app
وهذا سيعيد الصورة التي بنيتها آخر مرة.
هذا مفيد جدًا، شكرًا لك. من الناحية المثالية، نود الانتظار حتى يتم دمجه، ولكن نظرًا لأننا جدد في هذا الأمر، فليس من الواضح ما إذا كان ذلك سيستغرق أيامًا أو أسابيع أو أشهر.
شكرًا لك مرة أخرى.
لا يوجد نقد لهذا الطلب (لم ألقِ نظرة عليه بالتفصيل)، ولكن بشكل عام لا أعتقد أن هذه ممارسة جيدة.
هل تستفيد من مراجعة مطوري CDCK وتنتظر حتى تتم مراجعته ودمجه؟
هذه نصيحة جيدة.
مع ما اقترحته، قد تتمكن من رؤية أنها تعمل بالفعل (أو ربما هناك مواصفات فيها تجيب على هذا السؤال)، أو يمكنك الانتظار لفترة من الوقت حتى يتم قبولها. ينتظر الكثير من الناس أسابيع (أو أشهر) للترقية على أي حال.
@merefield شكراً - أعتقد أنك تقول انتظر حتى يتم دمجه، هل هذا صحيح؟
نحن نتفق، هذه فكرة رائعة. في هذه الأثناء، نحتاج إلى التعامل مع رفض رسائل البريد الإلكتروني.
مرة أخرى، نحن لا نعرف المدة التي تستغرقها العملية، لذلك بدون هذه المعرفة، سنفترض أنها ستستغرق وقتًا طويلاً.
ربما فاتني بعض الفروق الدقيقة هنا…
أعتقد أنك بأمان لتجربته لبضعة أسابيع. إذا كان هناك إصدار آخر، يمكنك تحديد ما إذا كنت ستحدّث طلب السحب الخاص بك للعمل مع الإصدار التالي أو تجد حلاً آخر. ربما يكون أسهل شيء هو القيام بذلك في إضافة (plugin)؟
انتظر. لماذا لا يتم ذلك في إضافة (plugin)؟
هذا هو المسار المعتاد للإجراء. قم بذلك في إضافة (plugin) ثم اسأل عما إذا كانوا مهتمين بطلب سحب. في الوقت الحالي، يبدو أنك الوحيد على وجه الأرض الذي يريد هذا. إضافته إلى النواة (core) تعني أن شخصًا ما سيحتاج إلى صيانته إلى أجل غير مسمى؛ إنه ليس بالأمر الهين.
نعم، لا أفهم لماذا لم يتم تطبيق هذا في إضافة.
بعد ذلك، يمكنك ببساطة تطوير الإضافة بشكل منفصل عن التثبيت الأساسي.
بمجرد (إذا) تم دمج طلب السحب، يمكنك بعد ذلك إزالة الإضافة!
نحتاج أيضًا إلى حل هذه المشكلة لتصحيحات الأمان غير العامة.
لدينا رمز في أدواتنا الداخلية يقوم بدمج فرع من مستودع - أوصي بنفس النهج لك.
شيء مثل هذا يجب أن يعمل لك في كتلة تنفيذ (ربما في خطاف after_code):
# جلب ودمج التصحيح
git merge REFERENCE --no-commit
bundle install # إذا لزم الأمر
pnpm install --frozen-lockfile # إذا لزم الأمر
@merefield @pfaffman الأمر ليس إضافة لأنه، بالنسبة لنا، هذا ليس بالأمر السهل. لم نكتب أي إضافة من قبل. إذا كان لدى أي شخص بعض التوجيهات حول كيفية ربط هذا، فسيسعدنا النظر فيه!
أيضًا، ربما لن أقول إننا الشخص الوحيد الذي “يريد” netcore - إنه أحد أكبر ESP… على وجه الأرض، وأكبر بكثير من بعض الآخرين المدعومين في النواة. لا أقترح أنه أفضل، أو قد يرغب المستخدمون في الآخرين، ولكن netcore هو ESP كبير جدًا وذو سمعة جيدة. في الواقع، يمكنك رؤية الكثير من الحديث عنه هنا، حيث كان يُعرف سابقًا باسم pepipost:
أعتقد أن استراتيجية مزدوجة ستكون مناسبة:
عدم القدرة على بناء إضافة ليس سببًا وجيهًا لطلب الدمج (PR).
لا يزال بإمكان الأطراف الثالثة استخدام إضافتك.
@merefield آسف، لماذا تعتقد أن بناء المكون الإضافي مرتبط بإنشاء طلب السحب؟ لقد كتب Netcore طلب السحب بأنفسهم.
ربما فاتني بعض التفاصيل فيما تقوله.
مجرد اقتراح. يمنحك مرونة إضافية في جداول النشر. من لا يحب الاعتماديات الأقل؟
لأنك تستطيع إنشاء مكون إضافي.
أنت لا تعرف ما إذا كانوا سيقبلون طلب السحب الخاص بك على الإطلاق. وأنا أيضًا لا أعرف.
إليك تلميح: استجاب شخص ما من الفريق في هذا الموضوع ولم يقل “نعم، سنقوم بتضمين هذا في أسرع وقت ممكن”. وبدلاً من ذلك، قدم لك “إليك ما نفعله إذا كان لدينا طلب سحب لن يتم قبوله في النواة لعدة أشهر”.
يبدو أن هذه هي خياراتك.
لا أقرأ الكثير في ردي.
أنا في جانب البنية التحتية، وليس لدي أي رؤية لأولويات فرق التطوير. بالنسبة لي، تبدو الالتزام 
ولكن قد يكون لدى عين أكثر خبرة رأي مختلف.
لكنني أعتقد أن الإجابة على هذا السؤال ستكون نصيحة مفيدة بشكل عام / أسئلة شائعة للمستضيفين الذاتيين.
في رأيي، سيكون المكون الإضافي ثقيلًا جدًا هنا.
[اقتباس=“Michael Brown, المشاركة:16، الموضوع:353444، اسم المستخدم:supermathie”]
في رأيي، ستكون الإضافة (plugin) ثقيلة جدًا هنا.
[/اقتباس]
حسنًا، هذا يوضح ما أعرفه.
وأظل أنسى حجم الموظفين الآن ومدى تجزئة الفرق. يبدو الأمر وكأنه بالأمس فقط عندما كان معظم الناس يعرفون معظم الأشياء (بالطبع حتى ذلك الحين كان لدى الناس تخصصاتهم)، ولكن “الأمس” كان قبل ثماني سنوات.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.