الخلاصة الأساسية: يثبت اجتياز مسار CI بنجاح أن الفحوصات الآلية قد اجتازت؛ لكنه لا يعني الموافقة على طلب سحب في متجر التطبيقات. إذا ظل إرسال تطبيق CasaOS/ZimaOS مفتوحًا لأشهر، فتوقف عن إعادة فحص الشارات نفسها، وحدد الطبقة التي لا تزال معلقة: التحقق من المستودع، أو ملاحظات المراجعين، أو متطلبات الدمج، أو مراجعة المشرف.
كان المثال الواقعي الذي تستند إليه هذه الصفحة مُعدًّا بعناية غير معتادة: فقد نُقل التطبيق إلى تنسيق v2، وكانت الفحوصات ناجحة، وثُبّتت وسوم Docker، واكتملت البيانات الوصفية، وكان المساهم يطرح سؤالًا بسيطًا: «هل هناك ما يمنع الدمج، أم توجد أي تغييرات مطلوبة من جانبي؟»
تحقق أولًا من الفحوصات المهمة فعلًا في مستودع متجر التطبيقات الحالي
يطلب مسار المساهمة الحالي في متجر التطبيقات من المساهمين تفرّع المستودع، وإجراء التغييرات واختبارها، ثم فتح طلب سحب يوضح ما تغيّر وكيف جرى التحقق منه.
للتحقق محليًا، يطلب المستودع تحديدًا من المساهمين تشغيل ما يلي:
./scripts/build_dist.shتكون النتيجة السليمة أكثر تحديدًا من مجرد «يبدو ملف Compose لديّ سليمًا». إذ ينبغي أن يكتمل البناء دون أخطاء، وأن ينتج dist/index.json، وإنشاء التطبيق الذي جرى تغييره ضمن dist/apps/<app-id>/.
تُجري فحوصات CI لمتجر التطبيقات في المستودع عملية التحقق من Compose وفحص بناء كاملًا للإصدار v2 على طلبات السحب. وقد يتسبب YAML غير الصالح، أو فقدان البيانات الوصفية المطلوبة للتطبيق، أو فقدان الأصول المشار إليها، أو عدم تطابق البنية، في فشل البناء.
اجتياز CI بنجاح ضروري، لكنه ليس قرار الدمج
هذه هي النقطة التي يغفل عنها كثير من المساهمين. لا يشير اجتياز الفحص الآلي بنجاح إلا إلى أن الالتزام استوفى الشروط التي اختبرها ذلك الفحص. وتختلف فحوصات حالة GitHub عن قرارات المراجعة والدمج.
يمكن أن يظل طلب السحب مفتوحًا لأنه يحتاج إلى:
- مراجعة من المشرف أو مالك الشيفرة؛
- معالجة التغييرات المطلوبة؛
- تحديث الفرع إلى أحدث إصدار؛
- حالة تعارض دمج تحتاج إلى حل؛
- قرارات القبول أو الانتقاء الخاصة بالمستودع التي لا تستطيع CI اتخاذها.
تتعامل متطلبات دمج GitHub مع المراجعات وفحوصات الحالة وقواعد الفروع باعتبارها شروط دمج منفصلة.
استخدم طلب الدمج نفسه لتحديد العائق
قبل نشر تعليق آخر من نوع «هل من تحديث؟»، تحقّق من أربعة أماكن:
- الفحوصات: تأكد من أن أحدث التزام، وليس SHA أقدم، قد اجتاز عمليات سير العمل المطلوبة.
- المحادثة: ابحث عن تعليقات المشرفين التي لم تُحل أو طلبات إجراء تغييرات.
- الملفات المتغيرة: تأكد من أن ترحيلك إلى v2 لم يُبقِ البيانات الوصفية القديمة في الموقع الخطأ.
- مربع الدمج: يخبرك GitHub عادةً ما إذا كانت لا تزال هناك حاجة إلى مراجعة أو فحص حالة أو حل تعارض أو تحديث الفرع.
إذا كانت CI ناجحة ولم يُظهر مربع الدمج أي عائق لا يستطيع المساهم إصلاحه، فمن المرجح أن تكون الخطوة المتبقية هي المراجعة البشرية، لا تغييرًا آخر في الشيفرة.
بالنسبة إلى طلبات v2، تحقّق من عقد المصدر، وليس من حاوية Docker فحسب
الحاوية العاملة ليست تلقائيًا إدخالًا صالحًا في متجر التطبيقات. يتوقع بروتوكول v2 الحالي أن يحتوي تعريف التطبيق المصدر على إعداد تشغيل قياسي لـ Docker Compose، بالإضافة إلى كتلة بيانات وصفية x-casaos في المستوى الأعلى. ويحدد مخطط البيانات الوصفية x-casaos حقولًا مثل id وmain وindex وport_map وicon وtitle والفئة والبنية وبيانات الإصدار.
لذلك، عندما يقول طلب ما «نجحت CI»، فالمتابعة المفيدة ليست «هل نجحت SonarQube؟» بل:
- هل
./scripts/build_dist.shنجح في أحدث فرع؟ - هل ينشئ التطبيق مخرجات v2 المتوقعة؟
- هل يمكن الوصول إلى جميع الأيقونات والصور المصغرة ولقطات الشاشة المشار إليها؟
- هل تتوافق البنية المعلنة مع الصورة؟
- هل بيانات الإصدار والإصدار الحالي محدثة؟
- هل تم حل جميع تعليقات المراجعة؟
كيفية المتابعة دون إحداث ضجيج
إذا ظل الطلب بلا نشاط لفترة طويلة، فانشر تحديث حالة موجزًا واحدًا بدلًا من تكرار العرض الأصلي كاملًا. تبدو المتابعة المفيدة هكذا:
طلب دمج: #888
آخر التزام: <SHA>
بناء v2: ينجح باستخدام ./scripts/build_dist.sh
إجراءات GitHub: ناجحة في أحدث التزام
تعليقات المراجعة المفتوحة: لا توجد
ما أحتاج إليه: تأكيد أي مانع متبقٍ من جانب المشرفوهذا يمنح المشرف سؤالًا يمكنه الإجابة عنه فورًا.
إذا كانت مراجعة المتجر الرسمي بطيئة، فإن المتجر التابع لجهة خارجية يمثل قناة توزيع صالحة
لا تقتصر منظومة v2 على مستودع واحد. كما توثق ZimaOS إعداد المتاجر التابعة لجهات خارجية للمستودعات المتوافقة. وإذا كان التطبيق يحتاج إلى توزيع مجتمعي قبل الدمج الرسمي، فقد يكون نشره عبر متجر تابع لجهة خارجية تتم صيانته بديلًا عمليًا ريثما يظل طلب السحب الأصلي مفتوحًا.
بالنسبة إلى المستخدمين وليس المساهمين، يشرح متجر تطبيقات ZimaOS نموذج التطبيقات بنقرة واحدة ومفهوم المتاجر التابعة لجهات خارجية. وتقدم منصة تطبيقات ZimaOS نظرة عامة على المنظومة الحالية. وإذا كنت تبني مضيفًا صغيرًا لاختبار التطبيقات التي تعتمد بكثافة على Docker، فإن ZimaBoard 2 منصة اختبار x86 مناسبة، وليست متطلبًا لإرسال تطبيق.
الأسئلة الشائعة
هل يعني اجتياز CI أن تطبيقي ينبغي أن يكون قد دُمج بالفعل؟
لا. يثبت CI فقط ما تتحقق منه عمليات سير العمل المؤتمتة. أما المراجعة البشرية وقواعد المستودع والتعليقات غير المحلولة والتعارضات وقرارات المشرفين فهي أمور منفصلة.
ما أمر التحقق المحلي الأكثر فائدة لمتجر التطبيقات الحالي؟
يشير دليل المساهمة في المستودع إلى ./scripts/build_dist.sh. تأكد من أنه ينتهي بنجاح وينتج ملفات v2 المتوقعة.
هل ينبغي أن أواصل تغيير الشفرة البرمجية إذا كانت جميع عمليات التحقق ناجحة؟
ليس من دون سبب محدد. افحص أولًا صندوق الدمج وراجع التعليقات. إذا لم يكن هناك مانع يمكن للمساهم معالجته، فاطلب قرار المراجعة المتبقي بدلًا من إجراء تغييرات تخمينية.
هل يمكنني نشر التطبيق خارج المتجر الرسمي؟
نعم. توثيق v2 الحالي يدعم صراحةً المتاجر المتوافقة مع ZimaOS التابعة لجهات خارجية، لذا يمكن أن يكون المتجر الخارجي قناة توزيع مشروعة.
