حسنًا، يسعدني سماع أنه يعمل! لدينا موقف “الدجاجة والبيضة” قليلاً نحتاج إلى حله. بعد الالتزام الذي أشرت إليه، يجب تشغيل assets:precompile مرة واحدة على الأقل قبل تشغيل db:migrate. ولكن العكس صحيح أيضًا - يحتاج assets:precompile إلى مخطط قاعدة بيانات محدّث.
من باب الفضول، ما هي عمليتك هنا؟ هل كنت تجري ترقية تعتمد على docker_manager عبر واجهة المستخدم؟ أم كان هذا ./launcher rebuild app؟ (أو شيء آخر تمامًا؟)
(أعتقد أنني بحاجة إلى إزالة git checkout main - لست متأكدًا من سبب وجوده)
آها. لكن Ansible يقوم بإسقاط قاعدة البيانات أولاً (هذا لموقع أستخدمه لعمليات الترحيل، لذا فإن البدء من جديد أمر متكرر). لذا هذا يتوافق مع بيضك. تنهد. لكن بعد ذلك قمت بإيقاف drop_database وقمت بتشغيله مرتين من Ansible، وفشل، ثم قمت بتشغيل التمهيد مرة أخرى من سطر الأوامر، ولا يزال يفشل. لا توجد أدلة على عمليات الترحيل:
Installing mysql2 0.5.5 with native extensions
Bundle complete! 137 Gemfile dependencies, 173 gems now installed.
Gems in the groups 'test' and 'development' were not installed.
Bundled gems are installed into `./vendor/bundle`
I, [2023-08-24T17:24:31.403199 #1] INFO -- : Replacing types { with set_real_ip_from 192.168.1.0/24;
set_real_ip_from 172.19.0.0/24;
set_real_ip_from 172.18.0.0/24;
set_real_ip_from 172.17.0.0/24;
set_real_ip_from 38.242.7.193/28;
real_ip_recursive on;
real_ip_header X-Forwarded-For;
types {
in /etc/nginx/conf.d/discourse.conf
I, [2023-08-24T17:24:31.403687 #1] INFO -- : > cd /var/www/discourse && su discourse -c 'LOAD_PLUGINS=0 bundle exec rake plugin:pull_compatible_all'
I, [2023-08-24T17:24:33.084210 #1] INFO -- : discourse-microsoft-auth is already at latest compatible version
I, [2023-08-24T17:24:33.084593 #1] INFO -- : > cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate'
rake aborted!
Errno::ENOENT: No such file or directory @ rb_sysopen - tmp/js-processor.js
/var/www/discourse/lib/discourse_js_processor.rb:140:in `read'
/var/www/discourse/lib/discourse_js_processor.rb:140:in `create_new_context'
/var/www/discourse/lib/discourse_js_processor.rb:156:in `block in v8'
/var/www/discourse/lib/discourse_js_processor.rb:154:in `synchronize'
/var/www/discourse/lib/discourse_js_processor.rb:154:in `v8'
/var/www/discourse/lib/discourse_js_processor.rb:169:in `block in v8_call'
/var/www/discourse/lib/discourse_js_processor.rb:168:in `synchronize'
/var/www/discourse/lib/discourse_js_processor.rb:168:in `v8_call'
/var/www/discourse/lib/discourse_js_processor.rb:193:in `perform'
/var/www/discourse/lib/pretty_text.rb:54:in `apply_es6_file'
ولكن هل يمكن أن يكون 'templates/enable-ruby-yjit.yml' هو المشكلة؟ تحرير: لم يكن هذا هو الحال. ثم قمت بإزالة قوالب mysql و import. لا يزال لا فائدة.
هل كانت هذه المشكلة موجودة منذ فترة؟ لقد قمت بترقية موقع آخر مؤخرًا وهو على ECS وبدا الأمر وكأن هناك شيئًا غريبًا يحدث مع الترحيل ثم تعطلت الأصول. إنها قاعدة بيانات ضخمة، لذلك اعتقدت أنني قد أكون غير صبور، كما أنني قمت ببعض هذه العملية يدويًا، لذلك اعتقدت أنني كنت أهملت.
@cvx قام بدمج هذا للتو والذي يجب أن يحل مشكلة الاعتماد المتبادل (بمجرد اجتيازه للاختبارات):
هذا منطقي .
نعتقد أن الخطأ يتم تشغيله إذا تضمنت أي ترحيلات لقاعدة البيانات استدعاءً لمحرك الترميز (PrettyText). في الغالبية العظمى من المواقع الحالية، هذا نادر. ولكن في موقع جديد تمامًا، نقوم بتعبئة مواضيع جديدة في قاعدة البيانات، والتي تتضمن معالجة بعض الترميز.
حسنًا، أرى هذا الالتزام عندما أقوم بـ git pull في بيئة التطوير الخاصة بي، ولكنه لا يزال يفشل، سواء من ansible أو عند تشغيله محليًا (وأنا لا أسقط قاعدة البيانات).
إنها بيئة إنتاج. تحتوي على traefiks كوكيل عكسي، ولكنها في الغالب تثبيت قياسي بخلاف ذلك (وقاعدة بيانات مبنية من صورة postgres13 القياسية، ولكنها تحتوي على pgvector).
لقد ذكرت بيئة التطوير الخاصة بي لأنني قمت بتشغيل git pull هناك محاولاً معرفة ما إذا كان الالتزام قد اجتاز الاختبارات؛ أرى FIX: Compile js-processor before db:migrate (#23229) في git log هناك).
سأعود لاختبار ما كنت أختبره من قبل وسأحاول مرة أخرى بعد قليل.
أعتقد أن بيئة التطوير الخاصة بك تعمل على main، وهذا هو سبب ظهور الالتزام. لقد واجهنا مشكلة في نظام التكامل المستمر الداخلي لدينا لاجتياز الاختبارات، ولكن نأمل أن يتم حل ذلك في غضون 30 دقيقة تقريبًا
.
