هذا التحديث يفشل بالنسبة لي، وفي الوقت الحالي، جميع منتديات Discourse الثلاثة الخاصة بي معطلة.
نافذة وحدة التحكم على شاشة الترقية لا تعرض أي شيء، ولكن بقية واجهة المستخدم تشير إلى أن الترقية لا تزال قيد التقدم (ولكن هذا استغرق بالفعل وقتًا أطول بكثير من أي تحديث قمت به على الإطلاق).
هل يواجه أي شخص آخر هذا؟ هل لديك أي أفكار حول كيفية إكمال الترقية بنجاح؟
@pearsonified لأن هذا يتضمن تحديثًا لمكون Rails، فهذه إحدى تلك الإصدارات التي تحتاج إلى تحديث من سطر الأوامر.
آه، هل هذه هي المشكلة مع خطأ ruby 3.0 و web-push-3.0.0؟
يجب أن يخبر تحديث المسؤول لواجهة المستخدم المستخدم بذلك بدلاً من السماح لهم بالنقر فوق “ترقية الكل” وينتهي بهم الأمر بمنتدى معطل تمامًا. وفر على الكثير من المستخدمين خفقان القلب.
لا فكرة لدي؛ أنا شخصياً لا أستخدم الواجهة الرسومية أبداً للتحديثات، أنا شخصياً أقوم بها دائماً من سطر الأوامر. لم أر أي أخطاء تبدو كذلك. ولكن حينها أيضاً لم أكن لأراها.
في معظم الأوقات عندما ترى رسالة خطأ عامة، إذا كان السيناريو المحدد يمكن توقعه بما يكفي لرسالة خطأ محددة، لكان قد تم تجنبه بدلاً من ذلك.
أعتقد أنه من الجيد أن مشكلة “مساعدة تحديث الواجهة الرسومية فشل” نادرة جداً لدرجة أن معظم الناس لا يدركون أن أول شيء يجب فعله هو فقط تشغيل git pull; ./launcher rebuild app للنشر الافتراضي. إنه دائماً الحل هنا تقريباً.
ولكن هذا هو الشيء العام الذي يجب فعله إذا فشل تحديث الواجهة الرسومية.
لقد كنت أستخدم discourse لسنوات عديدة. مثل 7؟ على أي حال، لم يفشل ترقية الويب بشكل كارثي من قبل. لقد فشلت بالطبع، لكن المنتدى عاد دائمًا إلى الحياة لأنه تراجع وبدأ الحاوية القديمة.
إنه ليس خطأ عامًا، فإن مشكلة الـ ruby واضحة جدًا.
web-push-3.0.0 يتطلب إصدار ruby >= 3.0، وهو غير متوافق مع
الإصدار الحالي، 2.7.6
مدير Docker: فشل الترقية
كنت سأشتكي بصوت عالٍ جدًا من هذا لو كنت دفعت مقابل Discourse. ليس بسبب وجود خطأ كبير أدى إلى تعطيل منتدياتنا، تحدث الأخطاء، ولكن لأنه لم يتم إصلاحه خلال الأيام الثلاثة الماضية على الأقل. على هذا النحو، مجرد القليل من الإثارة في نهاية اليوم.
من منظور مدير دوكر، لم يكن الكود وقت كتابة الإصدار الذي يعمل بالفعل يعلم أن هذه المشكلة ستحدث في المستقبل. أسمع أنك محبط، ولكن ما تطلبه قد لا يكون منطقيًا من الناحية الفنية.
إذا دفعت مقابل Discourse، لكانوا يديرون هذه العملية ولن تراها أبدًا. 
حتى لو كان الإصلاح مستحيلاً من الناحية الفنية، يمكنك إرسال رسائل بريد إلكتروني للمستخدمين لتحذيرهم من الترقية عبر CLI. أحدث بعض الضجة حول هذا الأمر. تعطيل المنتديات بدون تراجع هو أمر سيء.
أعتقد أن Discourse تبيع أيضًا الدعم للاستخدام المحلي؟ على أي حال، لا يمكنني الشكوى بصوت عالٍ جدًا لأنني لست عميلاً مدفوع الأجر، ولكن يا إلهي، 3 أيام ليست جيدة.
أنا سعيد من أجلك لأن هذه هي المرة الأولى منذ سبع سنوات التي تضطر فيها إلى العودة إلى هذا، ولكن:
سأعتبر ذلك تحريفًا. توصي CDCK بالفعل بعمل نسخ احتياطية قبل التحديثات كأفضل ممارسة. لقد رأيت مرات عديدة هنا على ميتا الملاحظة التي تفيد بأنه إذا فشل تحديث واجهة المستخدم الرسومية، فارجع إلى إعادة البناء من سطر الأوامر، كجزء من التوقعات العادية لإدارة منتداك الخاص. لم يعطلوا المنتديات بدون تراجع، لذا فإن تلميحك خاطئ.
لن أجلس هنا أجادل لساعات. أعتقد فقط أنك لست معقولًا تمامًا هنا.
علاوة على ذلك، فإن ترقية خادم الإنتاج دون تشغيل هذه الترقية عبر شكل من أشكال بيئة اختبارية هو مجرد طلب للألم.
لا يجب أن يكون نسخة كاملة النطاق، فإن $5 VPS تكفي لمعظم. إذا كنت ترغب في تجنب وقت التوقف والحاجة إلى اللجوء إلى النسخ الاحتياطي الخاص بك، فهو أرخص تأمين يمكنك الحصول عليه.
لقد اختبرت هذا للتو على نسخة تجريبية من DO لم يتم تحديثها منذ فترة طويلة:
وكما تم الإبلاغ عنه، فقد حدث خطأ:
Fetching gem metadata from https://rubygems.org/.........
Fetching https://github.com/rails/sprockets
web-push-3.0.0 requires ruby version >= 3.0, which is incompatible with the
current version, 2.7.6
Docker Manager: FAILED TO UPGRADE
#<RuntimeError: RuntimeError>
/var/www/discourse/plugins/docker_manager/lib/docker_manager/upgrader.rb:209:in `run'
/var/www/discourse/plugins/docker_manager/lib/docker_manager/upgrader.rb:93:in `upgrade'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:19:in `block in <main>'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.3.1/lib/active_support/fork_tracker.rb:20:in `block in fork'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.3.1/lib/active_support/fork_tracker.rb:18:in `fork'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.3.1/lib/active_support/fork_tracker.rb:18:in `fork'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:6:in `<main>'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/railties-7.0.3.1/lib/rails/commands/runner/runner_command.rb:43:in `load'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/railties-7.0.3.1/lib/rails/commands/runner/runner_command.rb:43:in `perform'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/thor-1.2.1/lib/thor/command.rb:27:in `run'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/thor-1.2.1/lib/thor/invocation.rb:127:in `invoke_command'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/thor-1.2.1/lib/thor.rb:392:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/railties-7.0.3.1/lib/rails/command/base.rb:87:in `perform'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/railties-7.0.3.1/lib/rails/command.rb:48:in `invoke'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/railties-7.0.3.1/lib/rails/commands.rb:18:in `<main>'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/bootsnap-1.13.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:32:in `require'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/bootsnap-1.13.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:32:in `require'
bin/rails:18:in `<main>'
Spinning up 3 Unicorn worker(s) that were stopped initially
وتظهر صفحة الترقية الآن:
والموقع الرئيسي يعرض خطأ 500. في /logs أرى هذا الخطأ:
NoMethodError (undefined method `navigation_menu' for #<Class:0x00007fdffcb1b2f8>)
lib/wizard/builder.rb:98:in `block in build'
lib/wizard.rb:25:in `append_step'
lib/wizard/builder.rb:61:in `build'
lib/wizard.rb:110:in `requires_completion?'
lib/wizard.rb:117:in `user_requires_completion?'
app/serializers/site_serializer.rb:171:in `include_wizard_required?'
…
@pearsonified @mcdanlj هل يمكنكما لصق الأخطاء التي كنتما تحصلان عليها؟
لا أعرف ما إذا كان بإمكاننا فعل أي شيء الآن لمنع هذا للمستخدمين المستقبليين، لكننا سننظر في الأمر.
في غضون ذلك، هل ساعدت الخطوات التالية؟
سأقوم بتشغيل ترقيات سطر الأوامر هذا الصباح وأرى كيف يسير الأمر. المنتديات معطلة منذ 18 ساعة 
إذا كنت تسألني نعم، فقد نجحت عملية إعادة بناء واجهة سطر الأوامر (CLI) بشكل جيد. أنا مسؤول أنظمة (SA) لائق ووجدت الحل في المنتديات هنا، ولكن يبدو أن أصحاب المنتديات الآخرين مثل @pearsonified قد تعرضوا لإزعاج شديد. 18 ساعة من التعطل، يا للهول.
الأشخاص الذين يتحدثون عن بيئات الاختبار والإنتاج هم خارج نطاق السيطرة. هناك الكثير من الأشخاص غير الشركات الذين يستضيفون منتديات Discourse على أجهزة افتراضية صغيرة. “يجب عليك الاختبار في بيئة اختبار” هو رد مهين ومتعجرف لا يبرر بأي حال من الأحوال كسر تثبيتهم. لا شيء يبرر ذلك.
أريد فقط التأكيد على أنني أقدر أن هذا البرنامج الممتاز مجاني تمامًا. أنا ممتن لذلك، والعقبات العرضية لا تغير مشاعري.
Discourse مجاني، والخوادم والنطاقات ووقتنا ليس كذلك.
هذا لا علاقة له ببيئات الشركات، إنه مجرد منطق سليم عندما تكون هناك العديد من المتغيرات قيد اللعب. يتم بذل الكثير من العمل لجعل الترقيات سلسة وإذا كنت تفضل إعطاء وقتك مجانًا لحل المشكلات الكبيرة فهذا قرارك - ولكن شخصيًا أفضل أن أعرف أن المجتمعات غير الربحية والمتطوعة التي أستضيفها ستكون معطلة مرة واحدة لترقية سهلة، بدلاً من فترة طويلة.
أصغر VPS في DO سيكون كافياً لتقليل مخاطر الترقيات طالما أن الاختبار ممثل - إذا كنت مسؤول نظام جيد، فإن 5 دولارات هي تكلفة فنجان قهوة، وجزء صغير من سعر ساعتك في السوق.
كانت آلة stg الافتراضية ستحتاج إلى الاحتفاظ ببيانات المنتدى أيضًا، مما سيضاعف تكاليف الاستضافة لدينا. إنها ليست ضرورية على أي حال، إنه منتدى ألعاب فيديو وبعض فترات التوقف (ليست 18 ساعة!) لا بأس بها. في أسوأ الأحوال، كان لدي لقطة آلة افتراضية قبل الترقية، لذا كان بإمكاني التراجع عنها ببساطة.
أجد أن الأيام الأربعة التي ظلت فيها معطلة أمر مقلق. يجب أن تؤدي الترقيات الفاشلة بدون تراجع إلى لحظة “يا إلهي، يجب إصلاح هذا الآن”. لا ينبغي أن يكون هذا تصريحًا مثيرًا للجدل.
لقد واجهت أيضًا خطأ web-push Ruby. منتدى عادي، لا توجد إضافات مخصصة.
يتطلب web-push-3.0.0 إصدار ruby >= 3.0، وهو غير متوافق مع
الإصدار الحالي، 2.7.6
كانت هناك أوقات سابقًا عندما قيل إنه يجب ترقيته عبر سطر الأوامر. ربما يمكن تمكين هذا الخيار الآن لأي إصدار يسبب هذه المشكلة؟
تعديل: أوه، إنه يقول ذلك بالفعل!
المشكلة هي أنه عندما تقوم بتحديث docker_manager ثم تنقر ببساطة على علامة التبويب في الأعلى بدلاً من تحديث الصفحة. لذا، هل يمكن تغييره للتحديث عبر HTTP بدلاً من مجرد تغيير علامات التبويب باستخدام JS؟