عن المشروع
Extra CODEOWNERS هو تطبيق GitHub App يستضاف ذاتياً للفرق التي ترغب في أتمتة الموافقة على طلبات السحب الروتينية بموجب سياسة CODEOWNERS. يقوم التطبيق بنشر فحص مطلوب (required check) يقبل إما موافقة بشرية من مالك الكود (CODEOWNER) أو موافقة من تطبيق GitHub App مسجل صراحةً. يمكن للمستودع أيضاً اختيار اعتبار مؤلف طلب السحب المؤهل كدليل على موافقة مالك الكود البشري لهذا الفحص. يظل الأشخاص والفرق في ملف CODEOWNERS القياسي الخاص بـ GitHub، بينما تحدد سياسة منفصلة التطبيقات التي يمكنها تغطية ملاك ومسارات محددة.
وُجد هذا المشروع لأن قاعدة "Require review from Code Owners" في GitHub تفهم الأشخاص والفرق ولكنها لا تسمح لتطبيق GitHub App بالحلول محلهم. فإذا كان تطبيق مثل Stampbot يعلم بالفعل أن طلب السحب روتيني، يظل GitHub ينتظر مالك كود بشري. يقوم Extra CODEOWNERS باستبدال هذا القرار الواحد بفحص يقوم بتقييم كل مجموعة ملاك فعالة بشكل منفصل، حيث يجب أن تجتاز كل مجموعة ملاك ممثلة بمسار مملوك هذا الفحص. قد يستخدم طلب سحب واحد موافقة بشرية لمجموعة ملاك وموافقة تطبيق لمجموعة أخرى. وتعتبر موافقة التطبيق مؤهلة فقط عندما تقوم المؤسسة بتسجيل هوية التطبيق بدقة، ويوافق المستودع على ذلك، وتغطي التفويضات المسار المتغير ومالك الكود الفعال، وتتوفر أي تسميات (labels) مطلوبة، وتطبق الموافقة على رأس طلب السحب الحالي، ولا توجد حماية على مستوى المؤسسة أو حماية مدمجة تجعل المسار مقتصرًا على البشر فقط. أما طلب السحب الذي يمزج بين مسارات مملوكة مفوضة وغير مفوضة، فلا يزال يتطلب تغطية بشرية لكل مجموعة ملاك غير مفوضة. والمسار الذي لا يتطابق مع أي CODEOWNERS فعال لا ينشئ متطلبات لمالك الكود، رغم أن الموافقات العادية والقواعد الأخرى تظل سارية.
يحتفظ GitHub بقواعد طلبات السحب العادية: الحد الأدنى لعدد الموافقات، والتعامل مع المراجعات القديمة، والالتزامات الموقعة، والفحوصات المطلوبة غير ذات الصلة. يهدف Extra CODEOWNERS إلى استبدال قاعدة "Require review from Code Owners" فقط. وبما أن عقد GitHub العام لا يوضح ما إذا كانت مراجعة تطبيق طرف ثالث تُحتسب ضمن الحد الأدنى للموافقات العادية، فيجب اختبار هذا المزيج في مستودع تجريبي قبل الاعتماد عليه. قد يتطلب الحد الأدنى غير الصفري وجود بشري حتى لو نجح فحص Extra CODEOWNERS. لا يقوم التطبيق بتقديم مراجعات، أو دمج طلبات السحب، أو منح تطبيق آخر حق الوصول، أو تحرير ملف CODEOWNERS؛ بل يقرأ أدلة GitHub وينشر تشغيل فحص واحد (Check Run).
يجب قراءة الفحص كـ نتيجة سياسة وليس كمراجعة. يظهر Extra CODEOWNERS في منطقة الفحوصات في GitHub، بينما يظهر عدد الموافقات العادية في منطقة المراجعة. يجب على الفرق الاحتفاظ بقاعدة الحد الأدنى للمراجعات العادية عند الحاجة. الفحص غير متزامن؛ فعندما يتم إلغاء موافقة أو تغييرها، يظل النجاح السابق مرئياً حتى يرسل GitHub الحدث ويقوم التطبيق بإعادة تعيين وتقييم الفحص. تقوم عملية المصالحة (Reconciliation) بإصلاح عمليات التسليم المفقودة، لكنها ليست آلية إلغاء فورية. لذا يجب الاحتفاظ بقاعدة مالك الكود الأصلية في GitHub للحدود التي لا تتحمل نافذة النجاح القديمة هذه.
ينقسم التفويض عبر نطاقين للسياسة: يحدد ملف CODEOWNERS الأشخاص أو الفرق التي تملك كل مسار. وتحدد سياسة المؤسسة التطبيقات الموثوقة بشكل عام، والمسارات التي لا يجوز لأي تطبيق تغطيتها. أما سياسة المستودع فتحدد أي تطبيق مسجل يمكنه تغطية أي مالك ومسار في ذلك المستودع. يمكن لسياسة المستودع تضييق سياسة المؤسسة، لكن لا يمكنها تسجيل تطبيق أو إضعاف حماية المؤسسة. تكون سياسة المستودع بتنسيق TOML وتتضمن schema_version و enabled و delegations التي تحتوي على app و paths و for_owners و required_labels. قيمة app هي اسم مستعار من جدول التطبيقات في سياسة المؤسسة، والذي يربط الاسم المستعار بالمعرف الرقمي الثابت للتطبيق، والslug العام، ومعرف مستخدم البوت. تتوفر ملفات سياسة نموذجية تحت examples/policy، ويغطي دليل التكوين كلا النطاقين، ومطابقة المسارات، والتسميات، والملفات المحمية المدمجة، ومخرج هروب غير آمن.
للفحص المحلي، يمكن تشغيل نسخة نظيفة باستخدام Bash و Git و mise عن طريق استنساخ المستودع وتشغيل mise trust و mise install و mise run bootstrap و mise run test. ينصح ملف README بقراءة mise.toml قبل mise trust لأن هذا الأمر يسجل قرار ثقة محلي. ينتهي التشغيل الناجح باجتياز مجموعة الاختبارات، ولكنه لا يسجل تطبيق GitHub App أو يثبت عقود GitHub الحية. لنشر فحص في مستودع اختبار، يتوفر دليل first-check. يجب أن تظل قواعد مالك الكود الأصلية مفعلة في أي مكان مهم. الصور والمخططات من إصدار Alpha مخصصة لاختبار وضع الظل (shadow-mode) غير المطلوب فقط ويجب تثبيتها بواسطة digest.
المشروع في مرحلة ما قبل الإصدار (pre-release). صور ومخططات Alpha مخصصة لاختبار وضع الظل غير المطلوب فقط ولا ينبغي أن تفرض عمليات دمج في بيئة الإنتاج. صور المعاينة القديمة مثل main ووسوم sha و sha256 المرافقة لها غير مدعومة وغير آمنة للنشر لأنها تسبق خط أنابيب الإصدار الثابت. تفصل وثيقة حالة المشروع بين ما هو قابل للاستخدام اليوم وما لا يزال يعيق الإصدار المدعوم. تتضمن الوثائق حالة المشروع، ومقارنة بـ CODEOWNERS الأصلي، ونموذج التهديدات، ودليل تثبيت التطوير، ودليل التكوين، ودليل استكشاف الأخطاء وإصلاحها، وأدلة النشر والعمليات، وحزم إشعارات المستلمين، وأدلة الهندسة المعمارية والمسؤولين، ودليل المساهمين. الدليل الكامل متاح على Read the Docs. تغطي سياسات المشروع الدعم، والإبلاغ عن الثغرات الخاصة، و CVEs و VEX الخاصة بـ OpenSSL، والحوكمة، وسجل التغييرات، ورخصة Apache License 2.0. تشير مجموعة الشارات إلى CI، واختبار الخصائص، والتغطية، و CodeQL، و OpenSSF Scorecard، والوثائق، و Python 3.12 إلى 3.14، وترخيص Apache-2.0.
Comments
0 Rating appears after 10 ratings
Sign in to join the discussion.