Tame Dependabot: قم بتجميع تحديثاتك، وإبطاء الإيقاع، والحفاظ على الأمان بسرعة

إذا احتفظت بمستودع نشط، فأنت تعرف هذا الشعور. تفتح إشعاراتك صباح يوم الاثنين وستجدها: خمسة، و10، وأحيانًا عشرات طلبات سحب Dependabot، كل منها يصطدم بتبعية واحدة من خلال إصدار تصحيح واحد. على حدة، كل واحد منهم مفيد. بشكل جماعي، هم الضوضاء. والضوضاء هي سبب تجاهل التحديثات المهمة.

لقد ألقينا نظرة على GCToolkit من Microsoft، وهي مكتبة Java مفتوحة المصدر لتحليل سجلات جمع البيانات المهملة. اعتبارًا من يوليو 2026، أ git log من المستودع أظهر ذلك 92 من أصل 578 التزامًا، أي ما يقرب من واحد من كل ستة، كانت عبارة عن نتوءات لإصدار Dependabot، مع 61 حالة في الأشهر الـ 12 الماضية وحدها، وفي بعض الأحيان عدة مرات في يوم واحد. هذا يعني الكثير من دورات المراجعة والدمج وCI التي تم إنفاقها على الصيانة الروتينية.

الخبر السار: يأتي Dependabot بالفعل مزودًا بالميزات لإصلاح هذه المشكلة. في طلب سحب حديث، قام المشروع بتغيير اسم dependabot.yml بثلاث طرق صغيرة ولكن ذات معنى، تحويل التنقيط اليومي من طلبات السحب ذات التبعية الفردية إلى دفعة شهرية مجمعة يمكن التنبؤ بها لكل نظام بيئي. إليك ما تغير، ولماذا يعمل، وكيفية تطبيق نفس النمط على مستودعاتك الخاصة، باتباع مثال GCToolkit.

المشكلة: الإعدادات الافتراضية الجيدة، والإيقاع الخاطئ

إليك ما بدا عليه تكوين GCToolkit من قبل:

version: 2
updates:
- package-ecosystem: github-actions
  directory: "/"
  schedule:
    interval: daily
  open-pull-requests-limit: 10

هذه نقطة بداية مشتركة، ولكن daily الفاصل الزمني هنا كان اختيارًا متعمدًا، وليس افتراضيًا: schedule.interval مطلوب، ويستخدم قالب البدء المقترح لـ GitHub weekly. هناك شيئان يجعلان هذا التكوين صاخبًا:

• interval: daily يخبر Dependabot بالتحقق من التحديثات كل يوم من أيام الأسبوع (من الاثنين إلى الجمعة). بالنسبة للمستودع الذي يشير إلى عدد قليل من إجراءات GitHub، فقد يعني ذلك وصول طلبات السحب الجديدة في أي يوم من أيام الأسبوع.
• لا يوجد تجميع يعني أن كل تبعية تحصل على طلب السحب الخاص بها. عشرة تحديثات متاحة تساوي 10 طلبات سحب، و10 عمليات تشغيل CI، و10 إشعارات مراجعة.

ال open-pull-requests-limit: 10 الخط هو عرض وليس علاجًا: فهو يحد من الفيضان عند 10 طلبات سحب مفتوحة، لكنه لا يوقف الفيضان.

الإصلاح: ثلاثة تغييرات على هذا المركب

وهذا هو التكوين بعد التغيير:

version: 2
updates:
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "monthly"
    groups:
      monthly-batch:
        patterns:
          - "*"

  - package-ecosystem: "maven"
    directory: "/"
    schedule:
      interval: "monthly"
    groups:
      monthly-batch:
        patterns:
          - "*"

هناك ثلاثة أشياء تحدث هنا، وهي مبنية على بعضها البعض.

1. قم بتجميع كل شيء في طلب سحب واحد

ال groups الكتلة هي قلب هذا التغيير:

groups:
  monthly-batch:
    patterns:
      - "*"

تقوم مجموعة Dependabot بتجميع تحديثات التبعية المتعددة في طلب سحب واحد. الاسم (monthly-batch) لك أن تختار. يظهر في عنوان طلب السحب واسم الفرع. ال patterns تحدد القائمة التبعيات التي تنتمي إلى المجموعة، و "*" هو حرف البدل الذي يطابق كل منهم.

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

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

يستمر التجميع في اكتساب المزيد من القدرة أيضًا. في تحديث فبراير 2026، اكتسب Dependabot القدرة على تجميع التحديثات لـ نفس التبعية عبر أدلة متعددة في طلب سحب واحد. وهذا يستهدف بشكل مباشر monorepos: إذا تم تثبيت مكتبة واحدة في عشرات الخدمات، فسيتم استخدام نتوء واحد لفتح عشرات طلبات السحب شبه المتطابقة، واحد لكل دليل. الآن يمكنك الإشارة إلى directories مفتاح (لاحظ الجمع) في قائمة المسارات، أو الكرة الأرضية مثل /apps/*، ودع مجموعتك تجمعهم جميعًا في واحد:

- package-ecosystem: "npm"
  directories:
    - "/apps/*"
  schedule:
    interval: "monthly"
  groups:
    monthly-batch:
      group-by: dependency-name
      patterns:Expand comment
        - "*"

هذا هو نفسه monthly-batch المجموعة كما كان من قبل، وتغطي الآن كل خدمة في المستودع بدلاً من دليل واحد. للحصول على المجموعة الكاملة من الخيارات، راجع مرجع خيارات Dependabot.

2. إبطاء الإيقاع من اليومي إلى الشهري

schedule:
  interval: "monthly"

التحول من daily ل monthly يغير الإيقاع من “كلما تغير أي شيء” إلى “مرة واحدة، وفقًا لجدول زمني يمكنك التخطيط له.” بالاشتراك مع التجميع، هذا هو تقليل الضوضاء الحقيقي: يتم فتح Dependabot الآن واحد طلب سحب مجمع لكل نظام بيئي، شهريًا، بدلاً من التدفق المستمر طوال الشهر.

إن النشرة الشهرية هي الدعوة الصحيحة لمكتبة ناضجة تكون فيها التبعيات مستقرة ونادرا ما تكون التحديثات عاجلة. إذا أردت شيئًا بينهما، weekly متاح أيضًا، ويمكنك تثبيت اليوم والوقت المحددين باستخدام schedule.day و schedule.time.

3. قم بتغطية كل نظام بيئي تستخدمه بالفعل

التكوين الأصلي يطلب فقط تحديثات الإصدار لـ github-actions. لكن GCToolkit هو مشروع Java تم إنشاؤه باستخدام Maven، لذا لم تكن تبعيات التطبيق الخاصة به تتلقى تحديثات إصدار Dependabot. يضيف التكوين المحدث ثانية updates دخول:

- package-ecosystem: "maven"
  directory: "/"

هذا هو واحد من السهل أن تفوت. الحد من الضوضاء هو نصف الربح فقط؛ النصف الآخر هو التأكد من أن Dependabot يراقب التبعيات الأكثر أهمية. يحصل كل نظام بيئي على جدول زمني خاص به ومجموعته الخاصة، لذلك تصل تحديثات الإجراءات الخاصة بك وتحديثات Maven كدفعتين نظيفتين ومنفصلتين.

ولكن ماذا عن التحديثات الأمنية؟

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

يتم رفع التحديثات الأمنية لـ Dependabot بمجرد الكشف عن ثغرة أمنية مع إصلاحها، بغض النظر عن جهازك schedule ومنفصلة عن مجموعات تحديث الإصدار الخاصة بك. لذا فإن إيقاع الدفعة الشهرية للمطبات الروتينية لا يؤخر التصحيح الحرج. (أنت يستطيع إصلاحات أمنية مجمعة عن قصد مع مجموعة محددة النطاق applies-to: security-updates، ولكن حتى في هذه الحالة يتم تشغيلها عن طريق الإفصاحات، وليس عن طريق الجدول الزمني لتحديث الإصدار الخاص بك.)

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

هذا الفصل هو ما يجعل توصية “إبطاء Dependabot” توصية آمنة وليست محفوفة بالمخاطر.

شبكة أمان جديدة: فترة تباطؤ الحزمة الافتراضية

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

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

شيئان يستحقان المعرفة:

• ينطبق فقط على تحديثات الإصدار. لا تزال التحديثات الأمنية مفتوحة على الفور، لذلك لا يتم إعاقة الإصلاحات الهامة أبدًا بسبب فترة التهدئة.
• يمكنك البقاء في السيطرة. استخدم cooldown الخيار في الخاص بك .github/dependabot.yml لتوسيع النافذة أو تقصيرها، أو ضبطها وفقًا لمستوى الإصدار الدلالي، أو إلغاء الاشتراك بالكامل:

- package-ecosystem: "maven"
  directory: "/"
  schedule:
    interval: "monthly"
  cooldown:
    default-days: 7
  groups:
    monthly-batch:
      patterns:
        - "*"

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

كيفية تطبيق هذا على المستودعات الخاصة بك

يمكنك اعتماد هذا النمط في بضع دقائق:

1. فتح (أو إنشاء) .github/dependabot.yml في الفرع الافتراضي لمستودعك.
2. لكل package-ecosystem تعتمد عليه، مجموعة schedule.interval ل weekly أو monthly.
3. أضف أ groups الحظر باستخدام مجموعة أحرف بدل واحدة (patterns: ["*"]) لتجميع التحديثات في طلب سحب واحد لكل نظام بيئي.
4. تأكد من إدراج كل نظام بيئي تشحن معه بالفعل: وليس فقط github-actions، لكن maven, npm, pip, gomod, docker، وما إلى ذلك.
5. الالتزام، والسماح للتشغيل المجدول التالي بإنتاج طلب سحب واحد ومجمع.

بعض النصائح أثناء ضبطه:

• ابدأ بشكل واسع، ثم انقسم. مجموعة أحرف البدل الواحدة هي أبسط نقطة بداية. إذا وجدت لاحقًا أنك تريد، على سبيل المثال، التعامل مع تحديثات مستوى التصحيح والإصدار الرئيسي بشكل مختلف، فقم بتقسيم حرف البدل إلى مجموعات مسماة أكثر استهدافًا.
• لا تقم بإضافة الإصلاحات الأمنية إلى هذا الإيقاع. يتم تشغيل التحديثات الأمنية لـ Dependabot من خلال الكشف عن الثغرات الأمنية، وليس من خلال جدول تحديث الإصدار الخاص بك، لذا فإن الإيقاع الشهري لا يؤخرها أبدًا. يمكنك حتى تجميعهم معًا applies-to: security-updates دون إبطائهم.
• الاعتماد على التهدئة. إن الإعداد الافتراضي لمدة ثلاثة أيام يحميك بالفعل من الإصدارات السيئة الجديدة تمامًا؛ نتوء cooldown.default-days أعلى إذا كنت تريد هامش أمان أوسع على تحديثات الإصدار.
• الحجم الصحيح للفاصل الزمني. قد تفضل التطبيقات سريعة الحركة weekly; المكتبات المستقرة تعمل بشكل جيد monthly.
• توحيد الدلائل monorepo. إذا كانت نفس التبعية موجودة في العديد من الدلائل، فقم بإدراجها ضمنها directories وتعيين group-by: dependency-name في المجموعة بحيث ينتج عن نتوء واحد طلب سحب واحد بدلاً من طلب واحد لكل دليل.

الوجبات الجاهزة

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

فعلت GCToolkit ذلك باستخدام حوالي عشرة أسطر من YAML: قم بتجميع كل شيء، وإبطاء الإيقاع إلى شهري، والتأكد من تغطية كل نظام بيئي. أضف فترة التهدئة الافتراضية الجديدة في الأعلى، وحتى تلك الدفعة الشهرية كان أمامها بضعة أيام لإثبات نفسها قبل أن تصل إليك. والنتيجة هي عدد أقل من طلبات السحب، وعدد أقل من مرات تشغيل CI، والأهم من ذلك، قائمة انتظار للمراجعة حيث لا تضيع التحديثات المهمة في التحديثات غير المهمة.

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