@zogstrip هل تمانع مراجعة هذا الـ PR نظرًا لأن لديك سياقًا من المراجعة الأخيرة التي قمت بها في هذا المجال؟ FIX: Make migrations from S3 more robust; fix bare URL migration by johnsonm · Pull Request #10093 · discourse/discourse · GitHub
لقد أدرجت فيه الإصلاحات التي قمت بها أثناء تنفيذ عملية الهجرة الكبيرة هذه. لم أحاول إضافة اختبارات لكل إصلاح؛ فأنا لست متأكدًا من كيفية حقن كل شكل من أشكال الأخطاء. لكن على الأقل الوظيفة الجديدة مُختبرة.
@RGJ أعتقد أن الـ PR الخاص بي كما هو الآن قد يتعامل مع جميع نقاطك ما عدا أول نقطتين، باستثناء أنني لست متأكدًا بشأن CDN. كان موقعي يستخدم CDN وهاجر مقاطع الفيديو التي تحتوي على عناوين URL من CDN، لكن قد يكون ذلك أثرًا جانبيًا لتسمية مساحات Discourse. إذا كانت لديك حالات إضافية، فآمل أن يمنحك الـ PR الخاص بي هيكلاً سهلًا لإضافته إلى التعبير النمطي (regex) وإضافة حالات اختبار للاختلافات الإضافية.
أعتقد أنه من الصحيح أولاً الهجرة حسب المنشور، لأنه بعد هجر المرفقات في منشور ما، يجب إعادة طبخ المنشور (re-bake) حتى يحتوي المنشور المطبوخ على عناوين URL الصحيحة. بعد الانتهاء من هجرة منشوراتي (والتي قد تستغرق أقل من أسبوعين الآن بعد أن غيّرت تحديد معدل السرعة للتحقق من طول الطابور مباشرة)، سأبحث في أي عمل متبقي لتنظيفه.
نظرًا لأن منشوراتًا متعددة يمكنها مشاركة مراجع لنفس المحتوى إذا قام أكثر من شخص برفع نفس الملف، فلا بد من مرحلة ثانية تفحص البيانات المطبوخة بحثًا عن عناوين URL القديمة وتعيد طبخ تلك المنشورات لاستيعاب الموقع الجديد. يمكنها استخدام نفس آلية تحديد معدل السرعة لتجنب إغراق الطوابير.
ربما لن أرى أي شعارات معطلة في makerforums لأننا قمنا بضبط الهوية البصرية بعد توقفنا عن وضع محتوى جديد في “s3” (بالنسبة لنا، DigitalOcean Spaces)، لكنني على الأرجح سأتعامل مع مجموعة من المرفقات التي لا تزال في S3 لصور الرموز الشخصية على الأقل. يجب بدء هجرة المرفقات غير المرتبطة بمنشور ما فقط بعد هجرة جميع المنشورات، وعلى الأرجح سأضطر إلى توثيق ذلك بعد الانتهاء من هجرة المرفقات في المنشورات.
@pfaffman أرى Bizarre Problems with migrate_from_s3 - #5 الذي يصف أخطاءً لم تتكرر. بدون إصلاحاتي في الـ PR الحالي، يتم تجاهل الأخطاء بصمت، بما في ذلك حالات فشل التحقق. أعتقد أن العمل هنا سيحل على الأقل بعض المشاكل التي واجهتها آنذاك.
@hosna المشاكل التي أثارها في https://meta.discourse.org/t/what-does-rake-uploads-migrate-from-s3-exactly-do/97285 تم حلها جزئيًا أو كليًا حتى الآن في هذا الـ PR. إذا لم تكن محلولة بالكامل، فقد أضفت اختبارات ستسهل إضافة اختبارات إضافية للتحقق من الإصلاحات الإضافية.
@sam بما أنك وضعت علامة 2.6 على الـ PR، فأنا أفترض أنه لن يتم دمجه على الأقل لبضعة أيام؛ هل يجب أن أسحب عملي على ميزة تحديد معدل السرعة إلى الـ PR جنبًا إلى جنب مع الإصلاحات؟ أم تفضل إبقاء الإصلاحات وعمل الميزات في طلبات سحب (PRs) منفصلة؟ يمكنني فعل أي من الأمرين. ميزة تحديد معدل السرعة تعمل بشكل ممتاز؛ فأنا أقوم بالهجرة بسرعة ثلاثة أضعاف تقريبًا، دون التأثير على توفر الموقع، الآن بعد أن انتظرت حتى يفرغ طابور Sidekiq، لذا يبدو من المنطقي دمجها، أعتقد، إذا كان ذلك شيئًا يُقبل عادةً في طلبات السحب. وإلا، فسأضطر إلى انتظار دمج الـ PR الذي يستند إليه العمل، لذا في كلتا الحالتين سيكون من الجيد سماع رأيك.
..
لقد قمت بتجريد (DRY) ترقيع حد معدل الهجرة الخاص بي وسحبتُه إلى الـ PR. إنه يعمل عمليًا، ويخبرني sar أنني أرى وقتًا خاملًا شبه معدوم بشكل مستمر، بينما يستمر الموقع في العمل، أثناء الهجرة المباشرة. إحدى مزايا وضع الدفعات هي أنه يمكنني التحقق من إصدارات Discourse الجديدة بعد كل دفعة كاملة من عمليات الهجرة؛ قمت بترقية موقعي إلى 2.6.0beta1 في أول فرصة بعد إصداره، وقد قمت بتشغيل عمليات الهجرة بنجاح على 2.6.0beta1 مع الـ PR الخاص بالهجرة فوقه منذ التحديث.
أعتقد أن الـ PR جاهز للمراجعة الآن؛ سأخطط لتقديم PR آخر للمراحل الأخيرة، لكن إدراج هذا سيحسن تجربة الهجرة العامة للجميع حتى قبل إكمال القطع الأخيرة.