نظرة عامة
لبناء إضافة قوية لـ Discourse، قد يكون من الحكمة تضمين التكامل المستمر (CI) في المكون الإضافي أو مكون السمة الخاص بك. سيساعد هذا في اكتشاف الأخطاء مبكرًا وتقليل احتمالية حدوث أخطاء في التعليمات البرمجية الخاصة بك.
يعد إعداد سير عمل \u003cabbr title="التكامل المستمر"\u003eCI\u003c/abbr\u003e باستخدام إجراءات GitHub لأتمتة عمليات البناء والاختبار نهجًا يستخدمه فريق Discourse في جميع مكوناتنا، ونوصي بأن تفعل الشيء نفسه.
الإعداد
لإضافة سير عمل مؤتمت لإجراءات GitHub للكشف عنها، تحتاج إلى إنشاء مجلد .github/workflows في الدليل الجذر للمستودع الخاص بك.
داخل مجلد workflows، يمكنك تحديد مجموعة من الأتمتة التي ستحتاج إجراءات GitHub إلى تشغيلها. على سبيل المثال، يمكن أن تكون هذه ملفات .yml للتدقيق والاختبارات.
لقد أنشأنا قوالب سير عمل لكل من المكونات الإضافية و مكونات السمة التي يمكنك الاستفادة منها. تتصل هذه بـ ‘تعريفات سير العمل القابلة لإعادة الاستخدام’ الخاصة بنا هنا.
في مستودع قالب القالب، على GitHub، يمكنك النقر فوق الزر \u003ckbd\u003eاستخدام هذا القالب\u003c/kbd\u003e لإنشاء مستودع مكون إضافي/مكون سمة بناءً على القالب.
بدلاً من ذلك، إذا كان لديك مشروع بالفعل ترغب في إضافة سير العمل إليه، فما عليك سوى نسخ سير العمل ذي الصلة إلى مجلد .github/workflows/ الخاص بمستودعك:
المكونات الإضافية: discourse-plugin.yml
السمات ومكونات السمة: discourse-theme.yml
\u003e 
هذه القوالب مقيدة بإصدار رئيسي محدد من سير العمل القابلة لإعادة الاستخدام. التحسينات الصغيرة التي نجريها على سير العمل ستدخل تلقائيًا حيز التنفيذ في السمة/المكون الإضافي الخاص بك. بالنسبة للتغييرات التي قد تؤدي إلى كسر التوافق (على سبيل المثال، تقديم مدقق جديد)، سنقوم بترقية الإصدار الرئيسي لسير العمل القابلة لإعادة الاستخدام، وستحتاج إلى تحديث سير العمل الخاص بك للإشارة إلى الإصدار الجديد.
ها أنت ذا! لقد تم إعداد كل شيء! ببساطة، قم بإنشاء التزام أو طلب سحب (PR) إلى المستودع الخاص بك وستقوم إجراءات GitHub بالكشف التلقائي عن سير العمل وبدء تشغيل المهام.
ستعرض إجراءات GitHub تفصيلاً لكل اختبار وبعد التشغيل، ستشير إما إلى 
أو 
اعتمادًا على ما إذا كان الاختبار قد نجح أو فشل.
إذا فشل اختبار، فإن النقر فوق التفاصيل سيعطيك بعض المعلومات حول ما فشل، مما قد يعطيك أدلة حول الخطأ في التعليمات البرمجية الخاصة بك وما يجب إصلاحه.
إضافة اختباراتك الخاصة
لكي تعمل اختبارات المكونات الإضافية والمكونات بفعالية، من المهم أن تكتب اختبارات للمكون الإضافي أو مكون السمة الخاص بك.
للحصول على تفاصيل حول كيفية كتابة اختبارات الواجهة الأمامية باستخدام EmberJS، راجع:
- Write acceptance tests and component tests for Ember code in Discourse
- Introduction - Testing - Ember Guides
لمزيد من التفاصيل حول كتابة اختبارات RSpec باستخدام Rails، راجع:
أمثلة
لصالحك، اخترنا عددًا قليلاً من الأمثلة للمكونات الإضافية ومكونات السمات التي تحتوي على اختبارات قوية مدمجة:
| المكون الإضافي / المكون | اختبارات جانب العميل | اختبارات جانب الخادم |
|---|---|---|
| Assign |  عرض المجلد |
عرض المجلد |
| Calendar | عرض المجلد |
عرض المجلد |
| Reactions | عرض المجلد |
عرض المجلد |
| Right Sidebar Blocks | عرض المجلد |
|
| Tag Icons | عرض المجلد |
|
| Table Builder | عرض المجلد |
\u003csmall\u003eهذه الوثيقة تخضع للتحكم في الإصدار - اقترح تغييرات على github.\u003c/small\u003e
\u003c!-- START DOCS ASSET MAP
[
{
“local_path”: “/assets/ci-with-github-actions-1.png”,
“local_sha1”: “c3fb59eeb13645670b751959d13cdf8e423e0fcf”,
“remote_short_url”: “upload://imziUfvg1AloA7IQ5jXMyn85Ngu.png”
}
]
END DOCS ASSET MAP –\u003e