التكامل المستمر
يعمل التكامل المستمر على GitHub Actions. سير العمل الرئيسي هو
.github/workflows/ci.yml.
لا يشغّل طلب الدمج إلا المهام التي تحتاج إليها ملفاته المتغيّرة، ومهمة تجميعية واحدة،
ci-success، هي بوابة الدمج.
كيف تُختار المهام
المهمة الأولى، changes، تقرأ مرشّحات المسارات في
.github/ci-paths.yml
باستخدام dorny/paths-filter. كل مرشّح قائمة من الأنماط؛ ويكون صحيحًا حين يطابق أي ملف
متغيّر أحدها. ولا تُشغَّل كل مهمة مشروطة إلا حين يكون مرشّحها صحيحًا.
- يسرد المرشّح كل ما تبنيه مهمته أو تختبره فعلًا: مصادر المهمة، والملفات التي تقرؤها
اختباراتها من خارجها، وملف سير عملها، و
Makefileحين تشغّلmake، وci.ymlنفسه (فالتغيير فيه قد يغيّر أي مهمة). - المجموعات المشتركة (المفاتيح التي تبدأ بـ
_، مثل_goو_pipelineو_web) مراسٍ في YAML تعيد المرشّحات استخدامها. - عند الدفع إلى
mainأوrelease/*، تكون كل المرشّحات صحيحة، لذا يحصلmainووسوم الإصدارات دائمًا على التشغيل الكامل. - يتحقق
tools/ci/ci_paths.pyمن المرشّحات في كل طلب دمج (ضمن مهمة الفحص الساكن): كل مهمة مشروطة بمرشّح أو معلَّمة بأنها تُشغَّل دائمًا، وكل مرشّح مستخدم، وكل ملف متتبَّع يقرؤه مرشّح ما أو مُدرَج على أنه لا تبنيه أي مهمة. إذا أضفت ملفًّا تبنيه مهمة أو تختبره، فأضفه إلى مرشّح تلك المهمة.
وهكذا فإن تغييرًا في pipeline/ يشغّل مهام الفحص الساكن واختبارات الوحدة لخط المعالجة، لا
بناء تطبيقات Apple أو Android؛ وتغييرًا في apps/android/ يشغّل مهام Android، لا اختبارات Go.
المهام
| المهمة | ما الذي تغطيه |
|---|---|
lint |
golangci-lint وgofmt وruff وmypy وeslint وtsc وprettier، وفحص الترحيلات والسجلات، وفحوص المستودع |
unit |
مستوى اختبارات الوحدة للغة Go وخط المعالجة وتطبيق الويب ورموز التصميم |
integration |
اختبارات على حاويات خدمتَي PostgreSQL وChroma |
replica، e2e، media-e2e، perf-ci |
مجموعات النسخ المتماثلة، ومن طرف إلى طرف، والوسائط، والأداء على حزم حقيقية |
build-artifacts، node-packaging، launcher |
الملفات التنفيذية المترجمة لعدة منصات، وأصول العُقد للإصدار، والمُشغِّل |
mac-app، win-app، linux-app |
تطبيقات الخادم لسطح المكتب |
apple-apps، android-apps، android-tv، desktop-player |
التطبيقات الأصلية واختباراتها واختبارات واجهاتها |
devportal |
بناء بوابة المطوّرين maktaba.dev واختباراتها |
pr-body-check |
متن طلب الدمج، بما في ذلك أي سبب للدمج القسري |
affected-tests |
أن الشيفرة المتغيّرة تغيّرت اختباراتها (راجع تشغيل الاختبارات) |
تستدعي كل مهمة سير عمل قابلًا لإعادة الاستخدام (_lint.yml و_unit.yml وغيرهما) يشغّل
أهداف make نفسها التي تشغّلها محليًّا. ولمُرحِّل السحابة سير عمله الخاص، relay.yml.
البوابة: ci-success
ci-success هو الفحص الوحيد الذي تشترطه حماية الفرع. وهو يعتمد على كل البوابات،
ويُشغَّل حتى حين يُتخطّى بعضها:
- المهمة التي تخطّاها مرشّح مساراتها تُعدّ ناجحة؛
- المهمة التي فشلت أو أُلغيت تُفشل
ci-success.
إضافة بوابة جديدة تعني إضافتها إلى ci-success.needs؛ أما حماية الفرع فلا تتغيّر أبدًا.
ما الذي يجب أن ينجح
قبل الدمج، يجب أن يكون ci-success أخضر. وعمليًّا:
- يجب أن تنجح كل مهمة اختارها التغيير؛ أما مهام الشيفرة غير المرتبطة فلا تُشغَّل ولا تؤخّر الدمج؛
- يجب أن تنجح
affected-tests، أو أن يحمل أحد الإيداعات التذييلNo-Test-Change: <reason>؛ - يُبلغ فحص الشيفرة CodeQL عن نتائجه في طلب الدمج أيضًا؛ والتنبيهات الجديدة عالية الخطورة تُفشله.
الدمج القسري
في حالات الطوارئ، يتيح الوسم force-merge مع سطر force-merge: <reason> في متن طلب الدمج
دمجَ الطلب دون أن تكون كل البوابات خضراء. هذا السطر هو سجل التدقيق:
تُفشل pr-body-check أي طلب دمج يحمل الوسم دون سبب.
طلبات الدمج من النسخ المتفرّعة
لا تصل مسارات العمل في النسخ المتفرّعة إلى أسرار المستودع، لذا تتخطى طلبات الدمج منها المجموعات المشروطة التي تحتاج إلى تلك الأسرار. يشرح تعليق آلي ذلك؛ ويراجع المشرف على المشروع الفروق ويعيد تشغيل تلك البوابات من فرع في المستودع الرئيسي قبل الدمج.
خريطة التغطية
بعد التكامل المستمر في كل دفع إلى main، يقيس coverage-map.yml أي الاختبارات تنفّذ أي
الملفات، وينشر النتيجة ملفًّا ناتجًا. وتستخدمه بوابة الاختبارات المتأثرة لإيجاد اختبارات الملف.
إعادة إنتاج فشل التكامل المستمر محليًّا
شغّل هدف make الخاص بالمهمة: make lint أو make test-unit أو make test-integration
أو make test-e2e أو make perf-ci. إذا اختلفت نتيجة التكامل المستمر عن نتيجة جهازك، فهذا
خلل في التطابق يستحق فتح مسألة.