أزالت GitHub Actions ‏Node 20: ما الذي ينبغي على مشرفي المشاريع مفتوحة المصدر فحصه الآن؟

انتقلت GitHub Actions من مرحلة التحذير إلى مرحلة التعطّل: لم يعد Node 20 متاحًا بوصفه بيئة تشغيل للإجراءات المكتوبة بجافاسكربت على المشغلات المستضافة لدى GitHub. ومنذ 23 سبتمبر 2026، تعمل تلك الإجراءات على Node 24، كما أزيل خيار التجاوز المؤقت الذي كان يسمح للمستودعات بالاستمرار في استخدام Node 20.

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

النصيحة العملية هي التعامل مع التغيير بوصفه تدقيقًا للإصدار ومصفوفة الدعم، لا مجرد استبدال السلسلة node20 بالسلسلة node24. تغيير بيئة التشغيل هو الحدث المباشر، أما المسألة الأعمق فتتعلق بالطريقة التي تعلن بها المشاريع مفتوحة المصدر عن المشغلات المدعومة، وتنشر بها حزم الإجراءات غير القابلة للتغيير، وتختبر بها البيئات التي يستخدمها الناس فعليًا.

ما الذي تغيّر في 23 سبتمبر؟

يذكر إشعار الإيقاف الصادر عن GitHub أن المشغلات تستخدم الآن Node 24 مع إجراءات جافاسكربت. ويذكر أيضًا أن المتغير ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION لم يعد متاحًا. كان هذا المتغير منفذًا مؤقتًا خلال فترة الانتقال، وليس آلية توافق مدعومة الآن. ويطبّق GitHub التغيير على github.com وعلى GitHub مع Data Residency.

من المهم التمييز بين بيئة تشغيل الإجراء وإصدار Node المثبت لسير العمل. يعلن إجراء جافاسكربت بيئة تشغيله في action.yml، عادة ضمن كتلة تشبه الآتي:

runs:
  using: node24
  main: dist/index.js

يتحكم هذا الإعداد في بيئة Node التي يستخدمها GitHub لإطلاق الإجراء. وهو منفصل عن خطوة لاحقة مثل actions/setup-node، التي تثبت إصدارًا من Node للأوامر الموجودة في عملية البناء أو الاختبار أو التغليف الخاصة بالمستودع. تثبيت Node 20 عبر setup-node لا يجعل إجراءً يعلن node20 متوافقًا مع مشغل أزيلت منه بيئة تشغيل إجراءات Node 20. وبالعكس، فإن تغيير بيئة التشغيل المعلنة للإجراء لا يغير تلقائيًا إصدار Node المستخدم في اختبارات المشروع.

لهذا يمكن أن يحتوي المستودع على عدة نقاط انتقال مستقلة:

• إجراءات جافاسكربت المعلنة في ملفات action.yml التابعة للمستودع نفسه.
• إجراءات خارجية مستعملة في ملفات سير العمل.
• شيفرة جافاسكربت المضمنة تحت dist/ إذا كان الإجراء يثبت ناتجه المترجم في Git.
• إصدارات المشغلات الذاتية وأنظمة التشغيل.
• إصدار Node الخاص بالمشروع، والمستخدم للاختبارات أو البناء أو أدوات سطر الأوامر أو نصوص الإصدار.

كان إشعار الإهمال السابق من GitHub قد منح المشرفين فترة انتقال، ووثق تاريخ الإزالة النهائي. كما يسجل Node.js أن Node 20 وصل إلى نهاية عمره في 24 مارس 2026. لذلك يزيل تغيير Actions مسار تنفيذ كان يعتمد أصلًا على بيئة تشغيل upstream غير مدعومة؛ وليس ذلك سياسة جديدة لإصدارات Node.js.

التدقيق الأول: اعثر على ما سينفذ فعلًا

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

.github/workflows/
action.yml
action.yaml
*/action.yml
*/action.yaml

في ملفات سير العمل، ابحث عن مراجع من نوع uses: owner/project@vN. لا تخبرك وسم رئيسية مثل vN ببيئة Node التي يستخدمها الإصدار المشار إليه. يجب فحص الإجراء عند الوسم أو الالتزام المحسوم. ويزداد ذلك أهمية في الإجراءات المجتمعية الصغيرة التي ربما تلقت تحديثًا على مستوى المصدر من دون نشر إصدار جديد.

إذا كان الإجراء مُدارًا داخل المستودع نفسه، فافحص action.yml وحدد قيمة runs.using. إذا كانت node20، فغيّرها إلى node24، ثم أعد بناء الناتج المضمن عندما يتوقع المشروع تثبيت dist/ في Git. تشغّل إجراءات جافاسكربت كثيرة ملفات مترجمة بدلًا من مصدر TypeScript أو JavaScript الموجود في المستودع. لذلك لا يكتمل الإصدار بتغيير المصدر مع إبقاء الحزمة القديمة.

السؤال التالي هو ما إذا كانت تبعيات الإجراء تدعم Node 24. فـ Node 24 ليس مجرد تسمية يقبلها محلل البيانات الوصفية. إنه يأتي بإصدار أحدث من V8 ومجموعة أحدث من واجهات Node، وقد يكشف افتراضات حول تحميل الوحدات، أو صادرات الحزم، أو سلوك OpenSSL، أو واجهات الملفات والتدفقات. لا يكمن الخطر في أن يفشل كل إجراء مبني لـ Node 20، بل في أن المشروع ربما لم يشغّل ناتج إصداره الفعلي تحت بيئة التشغيل الجديدة قط.

بالنسبة إلى الإجراءات الخارجية، فضّل إصدارًا منشورًا من المشرف يعلن دعم Node 24 صراحة. لا تفترض أن استبدال @v3 بـ @v4 صحيح لمجرد أن الرقم أكبر. اقرأ ملاحظات الإصدار، وافحص البيانات الوصفية للإجراء، وتحقق مما إذا كان الإصدار الجديد يقدم تغييرات سلوكية لا علاقة لها بالانتقال. انتقال بيئة التشغيل سبب ضعيف لقبول تغيير في الإصدار الرئيسي من دون مراجعة المدخلات والمخرجات والصلاحيات والسلوك الأمني.

لماذا تعد تحديثات الإجراءات الرسمية أمثلة مفيدة؟

تقدم إجراءات GitHub الرسمية صورة عملية لطريقة التعامل مع الانتقال. يسجل سجل تغييرات actions/checkout الحالي تحديثات Node 24 ضمن تاريخ إصداراته، كما تحدد وثائق actions/setup-node الحالية إصدارات أحدث تستخدم Node 24. ولا تكتفي هذه المشاريع بتعديل حقل واحد في البيانات الوصفية؛ فهي تنشر إصدارًا جديدًا، وتحدث الوثائق، وتشغل مصفوفة اختبارها، وتوضح متطلبات المشغل والتغييرات السلوكية.

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

ويذكّر مشروع actions/setup-node أيضًا بأن انتقال بيئة التشغيل قد يتزامن مع تغييرات أخرى. تصف وثيقته الحالية إجراءً مبنيًا على Node 24، وتقدم إرشادات حول التخزين المؤقت لمدير الحزم. وتحذر من أن التخزين المؤقت التلقائي ليس مناسبًا دائمًا لسير العمل ذي الصلاحيات المرتفعة أو بيانات الاعتماد الحساسة. لا ينتج هذا التحذير عن Node 24، لكنه مهم في التدقيق نفسه لأن المشرفين غالبًا ما يحدثون إصدارات الإجراءات وإعدادات أمان سير العمل معًا.

قد يحصل المستخدم الذي يرقّي إجراءً للحصول على دعم Node 24 على تغييرات في الإعدادات الافتراضية للتخزين المؤقت، أو سلوك المصادقة، أو إصدارات المشغلات المدعومة، أو اكتشاف مدير الحزم. لذلك لا ينبغي أن يكون سؤال المراجعة: هل تُحلل YAML؟ بل: ما الشيفرة التي تنفذ الآن، وبأي صلاحيات، وفوق أي حالة مخزنة مؤقتًا؟

المشغلات الذاتية هي نقطة الخطر الأوضح

يسمي إشعار الإيقاف حدين للتوافق مع Node 24: إصدارات macOS 13.4 والأقدم غير متوافقة، وARM32 غير مدعومة رسميًا. وتهم هذه الحدود المشاريع مفتوحة المصدر بصفة خاصة، لأن مجتمعات المساهمين والمستخدمين فيها أكثر تنوعًا من مصفوفة المشغلات المستضافة الافتراضية لدى GitHub. فقد ينجح بناء على Ubuntu، بينما يشغل المستخدمون الإجراء على جهاز Mac أقدم، أو جهاز من فئة Raspberry Pi بمعمارية ARM32، أو مشغل خاص خلف جدار ناري.

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

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

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

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

الحزمة المنشورة جزء من البرنامج

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

على المشرفين فحص القطعة الدقيقة التي سينفذها الإجراء عند مرجع الإصدار. ويعني ذلك التأكد من الأمور الآتية:

1. أن action.yml أو action.yaml يعلن node24.
2. أن مسار main أو pre يشير إلى الملف المولد المتوقع.
3. أن الملف المولد موجود في الوسمة المنشورة.
4. أن الإصدار بُني من الالتزام المقصود.
5. أن ملاحظات الإصدار تحدد الوسمة أو الالتزام الذي ينبغي للمستخدمين اختياره.
6. أن سير عمل الاختبار يشغل الحزمة المضمنة، لا المصدر وحده عبر اختصار تطوير.

على المشاريع التي تستخدم روبوت إصدار أو سير عمل بناء فحص ما إذا كان سير العمل نفسه يعتمد على إجراء قديم. يمكن أن يفشل الانتقال بصورة دائرية: يحدث المشرف الإجراء، لكن سير عمل الإصدار ما زال يستدعي إجراء checkout أو setup أو تغليف أو نشر قديمًا. حدّث CI الذي ينتج الحزمة قبل الاعتماد عليه لإثبات أن الحزمة حديثة.

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

دعم Node 24 لا يعني أن على المشروع تشغيل كل شيء عليه

توجد مسألتان مختلفتان للتوافق في المستودع الذي يحتوي إجراءً. الأولى: هل يمكن إطلاق الإجراء نفسه بواسطة بيئة Node 24 لدى GitHub؟ والثانية: هل يدعم تطبيق المشروع أو مكتبته أو مجموعة اختباراته أو أداة سطر الأوامر Node 24؟ وقد تكون لكل مسألة سياسة دعم مختلفة.

يمكن لإجراء أن يعمل على Node 24 بينما يستدعي مشروعًا لا يزال يدعم Node 18 و20 و22. بيئة تشغيل الإجراء تفصيل تنفيذي في منصة الأتمتة، أما البيئة المستخدمة لاختبار البرنامج فقد تكون وعدًا عامًا بالتوافق. لا ينبغي للمشرفين رفع الحد الأدنى لإصدار Node الخاص بالمشروع بصمت لمجرد أن GitHub غير بيئة تشغيل الإجراء.

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

strategy:
  matrix:
    node: [22, 24]
steps:
  - uses: actions/checkout@v7
  - uses: actions/setup-node@v7
    with:
      node-version: ${{ matrix.node }}
  - run: npm ci
  - run: npm test

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

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

قد تخفي المحاكيات المحلية المشكلة

الأدوات التي تشغل سير عمل GitHub Actions محليًا مفيدة، لكنها لا تعيد تلقائيًا سلوك المشغل المستضاف لدى GitHub. فقد تختار المحاكاة المحلية صورة حاوية فيها Node 16 أو Node 20، أو لا تطبق خريطة بيئة التشغيل نفسها، أو تستخدم إصدارًا مختلفًا من المشغل. لذلك لا يثبت نجاح التشغيل المحلي أن الحزمة المنشورة تعمل على بيئة Node 24 لدى GitHub.

توضح مشكلة في مشروع actions/checkout سبب الالتباس: قد تعرض أداة تنفيذ محلية صورة حاوية قديمة في الوقت الذي يستخدم فيه إصدار الإجراء Node 24. وليس الخلل بالضرورة في الإجراء، فقد يكون في نموذج بيئة التشغيل لدى المحاكي. على المشرفين تسجيل الأجزاء التي تم التحقق منها محليًا والأجزاء التي تتطلب مشغلًا مستضافًا حقيقيًا لدى GitHub أو مشغلًا ذاتيًا مضبوطًا بصورة صحيحة.

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

ما الذي ينبغي للمستخدمين تغييره في سير العمل؟

لا يحتاج المستخدمون عادة إلى إعادة كتابة كل خطوة في سير العمل. الأولوية هي تحديث مراجع الإجراءات إلى إصدارات تدعم Node 24، ثم فحص أي فشل متبقٍ. ابدأ بالإجراءات الأكثر مركزية في سير العمل: checkout، وsetup-node، والتخزين المؤقت، ورفع الملفات وتنزيلها، وإعداد اللغة، وعمليات الحاويات، وإجراءات النشر.

تبدو قائمة الترقية الآمنة هكذا:

• اقرأ ملاحظات إصدار الإجراء وتأكد من دعم Node 24.
• افحص الحد الأدنى الموثق لإصدار المشغل.
• راجع الصلاحيات والأسرار وإعدادات التخزين المؤقت وتغييرات المصادقة.
• اختبر طلبات الدمج القادمة من forks منفصلة عن عمليات الدفع الداخلية.
• اختبر سير العمل على كل نظام تشغيل ومعمارية تدعمهما فعليًا.
• أبقِ node-version الخاص بالمشروع أو ملف الإصدار صريحًا.
• أعد تشغيل وظائف الإصدار والنشر مع وجهة تجريبية أو وضع محاكاة.
• أزل متغيرات التجاوز القديمة الخاصة بـ Node 20؛ فهي لم تعد تقدم مسارًا احتياطيًا.

لا تخلط بين actions/setup-node وبيئة التشغيل المستخدمة في إجراءات uses:. يثبت سير العمل الآتي Node 24 لأوامر الصدفة:

- uses: actions/setup-node@v7
  with:
    node-version: 24
- run: npm test

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

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

ما الذي ينبغي للمشرفين وضعه في ملاحظات الإصدار؟

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

كما ينبغي تحديد الحدود المعروفة. فعلى سبيل المثال، يوضح إشعار GitHub أن macOS 13.4 والأقدم وARM32 لم تعودا مدعومتين لإجراءات جافاسكربت المبنية على Node 24. وإذا كان للمشروع قيد منفصل، مثل تبعية أصلية أو حد أدنى لإصدار المشغل أو حاجة إلى إصدار npm أحدث، فينبغي إدراجه في ملاحظة الإصدار نفسها.

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

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

الآثار الأمنية وآثار سلسلة التوريد

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

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

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

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

البدائل عندما لا يكون الإجراء قد انتقل

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

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

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

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

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

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

الدرس الأوسع لأتمتة المشاريع مفتوحة المصدر

تذكرنا بيئات التشغيل التي تديرها المنصات بأن للإجراء مفتوح المصدر عقدي صيانة. الأول مع منظومة المصدر: التبعيات، والمترجمات، ومديرو الحزم، وإصدارات اللغة. والثاني مع منصة الأتمتة: إصدارات المشغل، وأنظمة التشغيل المدعومة، ودلالات التنفيذ، والصلاحيات، وأعراف الحزم. يمكن للمشروع الوفاء بأحد العقدين ثم الإخفاق في الآخر.

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

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

بالنسبة إلى المستخدمين، المهمة المباشرة هي تحديث إصدارات الإجراءات المدعومة والتحقق من البيئات المهمة. أما المهمة الأهم للمشرفين فهي جعل الانتقال التالي مملًا وغير مفاجئ. ويتطلب ذلك سياسة دعم منشورة، ومتطلبات مشغل صريحة، وحزمة إصدار قابلة لإعادة الإنتاج، وCI يختبر المسار الذي ينفذه المستخدمون. Node 24 هو خط الأساس الجديد في GitHub Actions. وستقاس جودة الانتقال بدرجة أقل بكون ملف YAML قد تغير، وبدرجة أكبر بقدرة المساهمين على فهم الحد الجديد قبل أن يصل إلى الإنتاج.

المصادر وقراءات إضافية

• GitHub: لم يعد Node 20 متاحًا في GitHub Actions — إشعار الإيقاف، واعتماد Node 24، وإزالة خيار التجاوز، والبيئات المتأثرة في macOS وARM32.
• GitHub: إهمال Node 20 على مشغلات GitHub Actions — الجدول الزمني للانتقال والإرشادات السابقة للمشرفين والمستخدمين ومسؤولي المشغلات الذاتية.
• جدول إصدارات Node.js — تاريخ نهاية عمر Node 20 وحالة دعم Node 22 وNode 24.
• بنية البيانات الوصفية في GitHub Actions — إعلان runs.using في إجراءات جافاسكربت.
• سجل تغييرات actions/checkout — مثال رسمي على الإصدارات وتحديثات الوثائق المتعلقة بـ Node 24.
• مستودع actions/setup-node — الاستخدام الحالي، وصيغة إصدارات Node المدعومة، وإرشادات التخزين المؤقت، ومتطلبات المشغل.
• مستودع actions/runner — تنفيذ المشغل مفتوح المصدر وأتمتة ترقية Node فيه.
• سجل تغييرات GitHub: Actions — تغييرات ذات صلة بمنصة Actions ومنظومة المشغلات.