قام أحد العملاء بفرع discourse-rss-polling وقمت بتثبيته. ![]()
ولكن يبدو أنني ما زلت أملك النسخة الرسمية المثبتة:
![]()
سأترك كتمرين ملاحظة أن الالتزام (commit) المذكور ليس موجودًا في المستودع. عندما أضع المؤشر فوق الإضافة، أرى أنها تربط بالمستودع المفرع.
قام أحد العملاء بفرع discourse-rss-polling وقمت بتثبيته. ![]()
ولكن يبدو أنني ما زلت أملك النسخة الرسمية المثبتة:
![]()
سأترك كتمرين ملاحظة أن الالتزام (commit) المذكور ليس موجودًا في المستودع. عندما أضع المؤشر فوق الإضافة، أرى أنها تربط بالمستودع المفرع.
هه، ماذا نقول في هذا يا @سام؟
أعتقد أن هذا بالتأكيد خطأ، والحل البسيط هو التأكد من أن الإضافة تأتي دائمًا من discourse.org على GitHub ليتم تصنيفها كإضافة رسمية.
من الناحية التقنية، مع ذلك، لا يزال من الممكن الغش بسهولة نسبيًا.
الطريقة الوحيدة الدقيقة بنسبة 100% هي التحقق من أن الـ SHA المحدد هو SHA الخاص بنا، لكن هذا سيتطلب إنشاء خدمة أخرى.
في رأيي، سأضع هذا في قائمة “أشياء يتم إصلاحها خلال العامين أو الثلاثة أعوام القادمة”.
هذا ما خدعني أنا أيضًا مؤخرًا. لقد أضللتني علامة الصح بالتأكيد لفترة من الوقت، وقمت بجميع أنواع الاختبارات غير الضرورية قبل أن أكتشف المستودع في ملف app.yml.
يبدو أن إصلاحًا بسيطًا كافٍ تمامًا.
مثل المنشورات القصيرة جدًا، الهدف ليس جعل الغش في الاختبار مستحيلًا، بل فقط عدم الغش في الاختبار عن طريق الخطأ. ![]()
أسهل حل هنا خاص بإدارة حاويات Docker. لست متأكدًا من شعوري تجاه تشغيل أمر git إضافي أو البحث عن مستودعات git البعيدة في كل إضافة في كل مرة نبدأ فيها النظام.
لكن يمكن لإدارة حاويات Docker القيام بهذا العمل الإضافي ووضع أيقونة حمراء كبيرة على الإضافات الرسمية التي تبدو وكأنها مشتقة من نسخ أخرى.
سأخصص
للإصدار التالي، لذا سيحدث ذلك خلال الأشهر الستة القادمة تقريبًا.
pr-welcome أيضًا إذا كان أي شخص يرغب في تجربة إدارة حاويات Docker.
تم تطبيق مؤشر التفرع في طلب السحب هذا:
تم إغلاق هذا الموضوع تلقائيًا بعد 4 أيام. لم يعد مسموحًا بإضافة ردود جديدة.