مجموعة التزامن في GitHub Actions ليست حكماً على تسلسل النشر

ملخص

• يمتد التزامن في GitHub Actions إلى وظائف أو تشغيلات سير عمل تُحل إلى مجموعة تحمل الاسم نفسه؛ وقد يُستبدل العمل المنتظر أو يُصفّ في طابور أو يُلغى بحسب الإعداد.
• تميّز وثائق GitHub بين التزامن وenvironment: فسير عمل آخر يستخدم البيئة نفسها لا يخضع تلقائياً لقاعدة مجموعة مختارة.
• يتطلب القول إن النشر كان متسلسلاً ربط مفتاح المجموعة بعد توسعه، والأعضاء وحالاتهم، وسجلات التنفيذ، وملاحظة للوجهة؛ ولا يكفي الاسم المضبوط في الإعداد.

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

ويستحق السلوك الافتراضي قراءة دقيقة. تشرح GitHub أن المجموعة قد تضم عملاً قيد التنفيذ وعملاً واحداً منتظراً، وأن مرشحاً منتظراً أحدث قد يحل محل السابق. يغيّر queue: max هذا السلوك بالسماح بطابور محدود، بينما يمكن أن يلغي cancel-in-progress: true عملاً بدأ تشغيله بالفعل. ليست هذه الحالات نتيجة واحدة. فسجل دخول تشغيل إلى طابور لا يثبت بقاء التشغيل المنتظر قبله متاحاً. وسجل الإلغاء لا يبيّن الخطوات التي انتهت قبل الإلغاء. لذلك لا يصح قراءته دليلاً على عدم وقوع استدعاء خارجي أو نشر أثر أو تغيير في الوجهة.

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

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

يمكن لواجهة API الخاصة بمجموعات التزامن أن تعرض أعضاء مجموعة نشطة مع هويات التشغيل أو الوظيفة وحالة pending أو in-progress. وهذا دليل تشغيلي ذو قيمة، لكنه دليل آني ومحدود بالمنصة. ليس سجلاً لكل أمر وقع في الماضي ولا قراءة لحالة الوجهة. أما فحص الوجهة لاحقاً فيظل سجلاً مستقلاً يجب أن يحدد طريقته ووقته.

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

المصادر

1. GitHub Docs — Concurrency
2. GitHub Docs — Workflow syntax
3. GitHub Docs — Deploying with GitHub Actions
4. GitHub Docs — Actions concurrency groups REST API