محاكاة شبكة سيئة في CI

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

شكل الخطوة

أضعف الشبكة طوال مدة الاختبار ثم دعها تتوقف وحدها. لا توجد خطوة تنظيف يمكن نسيانها:

BeanNetworkTester.exe --loss 10 --latency 200 --target myapp.exe --duration 60

في مهمة GitHub Actions على مشغّل Windows مستضاف ذاتيًا:

- name: Test the app on a poor connection
  shell: pwsh
  run: |
    Start-Process -FilePath BeanNetworkTester.exe `
      -ArgumentList '--loss 10 --latency 200 --target myapp.exe --duration 90'
    npm test

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

لكل نهاية رمز خروج

لا شيء ينتهي بتتبّع أخطاء (traceback). لكل طريقة قد ينتهي بها التشغيل رقم، فيستطيع pipeline التمييز بين «فشل تطبيقك» و«تعذر بدء الأداة»:

الرمز	المعنى
0	انتهى كما طُلب.
1	فشل شيء أثناء التشغيل.
2	كان سطر الأوامر خاطئًا.
3	كان إعداد أو قيمة غير صالحة.
4	تم رفض ملف سيناريو.
5	تعذرت قراءة ملف أو كتابته.
6	لم يتحقق أحد الشروط المتعلقة بالتشغيل.
7	لا توجد صلاحيات مسؤول، لذا لا يمكن تحميل برنامج التشغيل.
130	تمت المقاطعة، عادةً بالضغط على Ctrl+C.
143	أُنهي من الخارج.

مخرجات تقرؤها الآلة

يكتب --format json كائن JSON واحدًا في كل سطر، أي عينات أثناء التشغيل وملخصًا في النهاية، لتتمكن خطوة لاحقة من التحقق منها:

BeanNetworkTester.exe --loss 5 --duration 30 --format json > run.ndjson

تذهب أسطر السجل إلى خرج الأخطاء القياسي والبيانات إلى الخرج القياسي، فلا يخلط إعادة توجيه البيانات بينهما أبدًا. يجعل --seed التشغيل قابلًا للتكرار، وهذا ما يحتاجه الاختبار غير المستقر (flaky) قبل أن يجادل أحد فيه.

تشغيل تجريبي لا يمس شيئًا

علَمان يجعلان توصيله آمنًا قبل أن تثق به: --dry-run يبلغ بما ستفعله الإعدادات ثم يخرج، و--simulate يشغّل المحرك كاملًا على حركة اصطناعية، دون تحميل برنامج التشغيل ودون المساس بالشبكة. وكلاهما مفيد في بناء لا يجوز أن يُدهور الجهاز الذي يعمل عليه.

هل أنت مستعد لتخريب شبكتك عمدًا؟

تنزيل لنظام Windows