يمكن لمشروعات البرمجيات النشطة أن تواجه عشرات طلبات السحب من Dependabot، بحيث يحدّث كل طلب اعتمادياً واحداً إلى إصدار تصحيحي جديد. ورغم فائدة هذه التحديثات منفردة، فإن تراكمها يستهلك دورات المراجعة والدمج والتكامل المستمر، وقد يجعل التحديثات المهمة تضيع وسط الضوضاء.
يعرض GitHub تجربة مشروع GCToolkit، وهي مكتبة Java مفتوحة المصدر لتحليل سجلات جمع البيانات المهملة، لتوضيح طريقة عملية لمعالجة المشكلة. ووفق سجل Git للمشروع حتى يوليو 2026، كان 92 من أصل 578 التزاماً عبارة عن ترقيات لإصدارات عبر Dependabot، منها 61 خلال الأشهر الاثني عشر السابقة. وفي بعض الأيام، كانت عدة طلبات سحب تصل في اليوم نفسه.
ثلاثة تغييرات في إعداد Dependabot
عدّل المشروع ملف dependabot.yml بثلاثة تغييرات مترابطة: تجميع التحديثات، إبطاء وتيرة الفحص، وإضافة منظومة Maven إلى الإعدادات. والنتيجة هي الانتقال من تدفق يومي لطلبات منفردة إلى دفعات شهرية يمكن توقعها لكل منظومة حزم.
التغيير الأول هو استخدام كتلة groups لجمع عدة تحديثات في طلب سحب واحد. ويحدد اسم المجموعة عنوان الطلب واسم الفرع، بينما تحدد قائمة patterns الاعتماديات المشمولة. وعند استخدام النمط العام *، يمكن جمع جميع التحديثات المتاحة في دفعة واحدة بدلاً من إنشاء طلب مستقل لكل اعتماد.
في المثال الذي يطرحه GitHub، قد تتحول عشرة تحديثات إلى طلب سحب واحد، وفرع واحد، وتشغيل واحد للتكامل المستمر، ومراجعة واحدة. وإذا فشلت الدفعة، تبقى المشكلة محصورة في مكان واحد قابل للمراجعة. أما المشروعات الأكبر، فيمكنها إنشاء مجموعات منفصلة، مثل مجموعة لمكتبات الاختبار وأخرى لاعتماديات الإنتاج.
وأصبح Dependabot في تحديث صدر خلال فبراير 2026 قادراً على تجميع تحديثات الاعتمادية نفسها عبر أدلة متعددة في طلب سحب واحد. ويستهدف ذلك المستودعات أحادية البنية التي تستخدم المكتبة نفسها في خدمات كثيرة. ويمكن إعداد مفتاح directories بقائمة من المسارات أو بنمط مثل /apps/*، مع استخدام group-by: dependency-name لضم التحديثات المتطابقة عبر الأدلة.
إبطاء التحديثات الروتينية دون تعطيل الأمان
كان إعداد GCToolkit يستخدم الفاصل daily لمنظومة GitHub Actions، ما يسمح بوصول طلبات جديدة في أي يوم من أيام العمل. يوصي المثال بدلاً من ذلك باستخدام monthly للمكتبات المستقرة التي لا تكون تحديثاتها عاجلة عادةً. ويمكن اختيار weekly للمشروعات الأسرع حركة، مع تحديد اليوم والوقت عبر schedule.day وschedule.time عند الحاجة.
أما السطر open-pull-requests-limit: 10، فيحد عدد الطلبات المفتوحة لكنه لا يعالج سبب التدفق. فالحل الأساسي هو الجمع بين الجدولة المناسبة وتجميع التحديثات، وليس الاكتفاء بتحديد سقف للطلبات.
ويشدد المصدر على أن إعدادات مجموعات التحديث والجدول الزمني تخص تحديثات الإصدارات، ولا تؤخر تحديثات الأمان في الإعداد الافتراضي. إذ ينشئ Dependabot تحديثاً أمنياً عند الكشف عن ثغرة يتوفر لها إصلاح، بصورة مستقلة عن جدول تحديثات الإصدارات ومجموعاتها. ويمكن، عند الرغبة، تجميع إصلاحات الأمان باستخدام مجموعة مخصصة تتضمن applies-to: security-updates، لكنها تظل مرتبطة بظهور الإفصاحات الأمنية لا بجدول التحديثات الروتينية.
وتعتمد هذه الحماية على تفعيل تحديثات Dependabot الأمنية في المستودع، إلى جانب تمكين dependency graph وتنبيهات Dependabot. لذلك ينبغي التحقق من تفعيل هذه المكونات قبل الاعتماد على وتيرة شهرية للتحديثات العادية.
فترة تهدئة للإصدارات الجديدة
يتضمن Dependabot حالياً فترة تهدئة افتراضية مدتها ثلاثة أيام قبل إنشاء طلب تحديث لإصدار جديد ظهر في سجل الحزم. والهدف هو منح المجتمع والمشرفين وقتاً لاكتشاف الإصدار المخترق أو المعطوب قبل دمجه في المشروع، إذ قد تكون الإصدارات الجديدة نقطة دخول لهجمات سلسلة توريد البرمجيات.
تنطبق فترة التهدئة على تحديثات الإصدارات فقط، بينما تظل تحديثات الأمان فورية. كما يمكن تعديلها من ملف .github/dependabot.yml لزيادة المدة أو تقليلها، وضبطها وفق مستوى الإصدار الدلالي، أو تعطيلها. ويعرض المصدر مثالاً على ضبط القيمة الافتراضية إلى سبعة أيام باستخدام cooldown.default-days: 7.
تطبيق النمط على المستودعات
يمكن البدء بفتح أو إنشاء ملف .github/dependabot.yml في الفرع الافتراضي للمستودع، ثم تطبيق الإعدادات التالية:
- اختيار فاصل زمني أسبوعي أو شهري لكل منظومة حزم مستخدمة.
- إضافة مجموعة عامة باستخدام patterns: ["*"] لجمع التحديثات في طلب واحد لكل منظومة.
- إدراج جميع المنظومات المستخدمة فعلياً، مثل GitHub Actions وMaven وnpm وpip وgomod وDocker.
- تجربة مجموعة عامة أولاً، ثم تقسيمها لاحقاً إذا تطلبت تحديثات التصحيحات أو الإصدارات الرئيسية معالجة مختلفة.
- استخدام فترة التهدئة الافتراضية أو تمديدها للحصول على هامش أوسع قبل تحديثات الإصدارات.
- تجميع الأدلة المتعددة في المستودعات أحادية البنية مع ضبط التجميع وفق اسم الاعتمادية.
الخلاصة أن تقليل ضوضاء Dependabot لا يتطلب إيقافه أو دمج طلباته بلا مراجعة. يوصي المثال بجعل التحديثات الروتينية هادئة ومجمعة، مع إبقاء الإصلاحات الأمنية قادرة على الوصول فوراً. وبحسب تجربة GCToolkit، أدى الجمع بين التجميع والوتيرة الشهرية وتغطية منظومات الحزم وفترة التهدئة إلى تقليل طلبات السحب وتشغيلات التكامل المستمر، مع الحفاظ على أولوية التحديثات المرتبطة بالثغرات.