إدارة برمجية لشرط تغطية الشيفرة

أعلنت GitHub إتاحة استخدام REST API المتاح عموماً لإدارة خيار تقييد تغطية الشيفرة ضمن قواعد المستودعات. ويتيح هذا التغيير للمستخدمين إنشاء هذا الخيار وتحديثه وقراءة إعداداته برمجياً، إلى جانب إمكانية ضبطه من خلال واجهة GitHub على الويب.

يرتبط الخيار بقواعد المستودعات التي تفرض متطلبات محددة قبل قبول التغييرات. وبدلاً من الاقتصار على الإعداد اليدوي من واجهة المستخدم، يمكن الآن التعامل مع شرط تغطية الشيفرة باعتباره إعداداً قابلاً للإدارة من خلال الأدوات والعمليات البرمجية المعتادة.

حد أدنى للتغطية أو سقف للتراجع

تسمح قاعدة Restrict code coverage بفرض حد أدنى لنسبة تغطية الشيفرة، على أن يستند القياس إلى تغطية الأسطر. وبهذا يمكن للمستودع اشتراط مستوى محدد من التغطية قبل تمرير التغيير وفق الإعداد المعتمد للقاعدة.

كما يمكن استخدام القاعدة لتحديد أكبر انخفاض مقبول في تغطية الشيفرة ضمن طلب سحب. ويمنح هذا الخيار فرق التطوير طريقة لمراقبة التراجع في التغطية، بدلاً من التركيز فقط على بلوغ نسبة ثابتة في كل تغيير.

وتجمع القاعدة بذلك بين نمطين لإدارة متطلبات التغطية: اشتراط مستوى أدنى للتغطية، أو منع طلبات السحب من تجاوز مقدار محدد من الانخفاض. ويعتمد السلوك الفعلي على الإعداد الذي يختاره المسؤول عن المستودع.

تكامل مع البنية التحتية كرمز

بحسب GitHub، تجعل الإتاحة البرمجية إدارة متطلبات تغطية الشيفرة أكثر اتساقاً عبر عدد كبير من المستودعات. فبدلاً من إعادة ضبط القاعدة يدوياً في كل مستودع، يمكن تضمين الإعداد ضمن عمليات الإدارة المؤتمتة التي تستخدم REST API.

وتفيد هذه الإمكانية أيضاً في سير العمل القائم على مفهوم البنية التحتية كرمز، إذ يمكن قراءة إعداد القاعدة وإنشاؤه وتحديثه من خلال إجراءات قابلة للتكرار. ويساعد ذلك على توحيد متطلبات التغطية بين المستودعات التي تتبع سياسة جودة واحدة، مع إبقاء ضبط القاعدة قابلاً للمراجعة والإدارة ضمن العملية البرمجية المعتمدة.

ولا يعني دعم REST API إلغاء واجهة الويب؛ فالخيار كان متاحاً عبر الواجهة، بينما تضيف الإتاحة الجديدة مساراً برمجياً لإدارة الإعداد نفسه. ويأتي التغيير لتوسيع طرق التحكم في القاعدة، لا لاستبدال طريقة الضبط الحالية.

المتطلبات اللازمة لتفعيل القاعدة

يتطلب استخدام شرط تغطية الشيفرة أن يكون GitHub Code Quality مفعّلاً في المستودع. كما يجب إعداد عمليات رفع تقارير تغطية الشيفرة حتى تتوافر البيانات التي تعتمد عليها القاعدة عند تقييم الحد الأدنى أو مقدار التراجع.

وبناءً على ذلك، لا يكفي إنشاء إعداد القاعدة عبر REST API وحده لتقييم التغطية؛ إذ تشير GitHub إلى ضرورة توفر تمكين Code Quality وضبط رفع بيانات التغطية أولاً. ويجب أن تتوافق عملية إعداد المستودع مع هذه المتطلبات قبل الاعتماد على الشرط في طلبات السحب.

تتيح واجهة REST API التعامل مع الخيار ضمن إدارة قواعد المستودعات، بينما تبقى نتيجة تطبيق الشرط مرتبطة بتوافر تقارير التغطية المرفوعة والإعداد الذي يحدده المستودع. وتساعد هذه العلاقة على إبقاء متطلب التغطية جزءاً من سياسة الجودة بدلاً من كونه إعداداً منفصلاً عن بيانات القياس.

نطاق الإتاحة للخطط

أوضحت GitHub أن هذه الإمكانية متاحة على GitHub Enterprise Cloud وGitHub Team، وتشمل أيضاً GitHub Enterprise Cloud مع توطين البيانات. ويعني ذلك أن فرق المؤسسات والمشروعات التي تستخدم هذه الخطط تستطيع إدارة خيار تغطية الشيفرة عبر الواجهة البرمجية العامة، متى استوفت متطلبات Code Quality ورفع التقارير.

في المقابل، لا تتوفر الميزة على GitHub Enterprise Server وفق الإعلان. لذلك يختلف نطاق الاستخدام بحسب المنتج والخطة التي يعتمدها المستودع، ولا يمكن افتراض توفر الخيار نفسه في البيئات المستضافة ذاتياً على Enterprise Server.

تندرج الإتاحة ضمن دعم GitHub المتزايد لإدارة قواعد المستودعات عبر الواجهات البرمجية. وللاطلاع على بقية القواعد المدعومة وتفاصيل نقاط REST API، تحيل الشركة إلى وثائق القواعد الخاصة بمجموعات القواعد ووثائق نقاط النهاية المرتبطة بها.

المصادر

• GitHub ChangelogManage the code coverage ruleset condition with the REST API