المشغِّلات

يعمل سير العمل المعرَّف على on: push عند كل دفعة (push) وعلى كل فرع، حتى عندما لا يمس الـ commit سوى الملف README.md. وفي فريق من خمسة أشخاص، يعني ذلك سريعًا مئات عمليات التنفيذ الأسبوعية، لا يتحقق أغلبها من أي شيء مفيد. والمشكلة ليست في كلفة الدقائق المفوترة فحسب، بل في طابور الانتظار أيضًا. فحين تشغل عشرون عملية تنفيذ غير مجدية الـ runners، تنتظر العملية التي تعطّل دمجًا عاجلًا خلفها.

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

push وpull_request: التكرار الشائع

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