لقد كنت ألعب بهذا التحدي ووجدت حلاً في Github.
لذلك، فإن مجرد وجود علامة خضراء لأحدث مهمة CI ليس كافياً، حيث قد تكون هناك تغييرات حديثة قد تؤدي إلى تعطل المكون الإضافي. بشكل أساسي، تحتاج إلى إعادة تشغيل مهام CI عندما تقوم Discourse بتحديث الفروع.
في مستودع المثال هذا قمت بتطوير حل فعال. إنه في الأساس سير عمل مجدول يتحقق من الفروع المهمة لمستودع Discourse لمعرفة ما إذا كانت هناك تغييرات، وإذا كانت هناك، فسيؤدي ذلك إلى تشغيل سير العمل العادي لـ CI الذي يجب أن يقوم بتشغيل مجموعة الاختبارات. في ملف القراءة الخاص بك، يمكنك بعد ذلك وضع بعض الشارات لإظهار كيف تم تشغيل مهام سير عمل CI ضد أحدث التغييرات.
سير العمل للمراقبة يعمل في ثوانٍ. لذلك، عند جدولته، سيستهلك دقيقة واحدة فقط من وقت إجراءات Github.
من الواضح أن موثوقية هذه الإعدادات بأكملها تعتمد على جهود مطور المكونات الإضافية/مكونات الثيم في إنشاء مجموعة اختبارات جيدة.
ولا يزال لديك مشكلة تجربة المستخدم حيث لا تعرف من صفحة “التحديث” في Discourse ما إذا كانت أحدث مهمة CI قد فشلت لإصدار معين.
لذلك، بالإضافة إلى وجود سير عمل للمراقبة يعيد بناء مكون إضافي عند تغيير فرع Discourse، تحتاج إلى إنشاء قطعة بناء تسجل النتيجة (نجاح/فشل). في بيانات المكون الإضافي الخاص بك، يجب أن تكون قادرًا على الإشارة إلى هذه القطعة، ويجب على Discourse استرداد هذه القطعة لعرض التوافق/النتيجة في واجهة التحديث.
إنه ليس بناءً مضمونًا، ولكنه شيء.