chore(i18n): refresh ar translations
This commit is contained in:
openclaw-docs-i18n[bot]
parent
9c3c1e4a05
commit
14c8ca1b6a
346
docs/ar/ci.md
346
docs/ar/ci.md
@ -1,75 +1,75 @@
|
||||
---
|
||||
read_when:
|
||||
- تحتاج إلى فهم سبب تشغيل مهمة CI أو عدم تشغيلها
|
||||
- أنت بصدد تصحيح فشل في فحص GitHub Actions
|
||||
- أنت تنسّق تشغيلًا للتحقق من الإصدار أو إعادة تشغيله
|
||||
summary: رسم بياني لوظائف CI، وبوابات النطاق، ومظلات الإصدار، ومكافئات الأوامر المحلية
|
||||
- أنت تصحح أخطاء فحص فاشل في GitHub Actions
|
||||
- أنت تنسّق تشغيل عملية التحقق من صحة الإصدار أو إعادة تشغيلها
|
||||
summary: مخطط مهام CI، وبوابات النطاق، ومظلات الإصدار، ومكافئات الأوامر المحلية
|
||||
title: مسار CI
|
||||
x-i18n:
|
||||
generated_at: "2026-04-30T07:45:53Z"
|
||||
generated_at: "2026-04-30T18:38:55Z"
|
||||
model: gpt-5.5
|
||||
provider: openai
|
||||
source_hash: a9c18f0801864ca1030aac9ea81117b011bd7936388984a1809ce3ae6e906e62
|
||||
source_hash: a24afc27606ac7f4e9ead89acdd319bffa23336610f8a6cd8b576ea1a5b233dd
|
||||
source_path: ci.md
|
||||
workflow: 16
|
||||
---
|
||||
|
||||
يدير OpenClaw CI على كل دفع إلى `main` وكل طلب سحب. تصنّف مهمة `preflight` الفروق وتوقف المسارات المكلفة عندما تتغير مناطق غير ذات صلة فقط. تتجاوز عمليات تشغيل `workflow_dispatch` اليدوية تحديد النطاق الذكي عمدًا وتوسّع الرسم البياني الكامل لمرشحي الإصدار والتحقق الواسع. تبقى مسارات Android اختيارية عبر `include_android`. تقع تغطية Plugin الخاصة بالإصدارات فقط في سير العمل المنفصل [`Plugin ما قبل الإصدار`](#plugin-prerelease)، ولا تعمل إلا من [`Full Release Validation`](#full-release-validation) أو من تشغيل يدوي صريح.
|
||||
تشغّل منظومة CI الخاصة بـ OpenClaw عند كل دفع إلى `main` وكل طلب سحب. تصنّف مهمة `preflight` الفرق وتوقف المسارات المكلفة عندما تتغير مناطق غير مرتبطة فقط. تتجاوز عمليات التشغيل اليدوية عبر `workflow_dispatch` النطاق الذكي عمدًا وتوسّع التنفيذ إلى الرسم البياني الكامل لمرشحي الإصدار والتحقق الواسع. تبقى مسارات Android اختيارية عبر `include_android`. توجد تغطية Plugin الخاصة بالإصدار فقط في سير عمل [`Plugin Prerelease`](#plugin-prerelease) المنفصل، ولا تعمل إلا من [`Full Release Validation`](#full-release-validation) أو من تشغيل يدوي صريح.
|
||||
|
||||
## نظرة عامة على خط الأنابيب
|
||||
|
||||
| المهمة | الغرض | متى تعمل |
|
||||
| المهمة | الغرض | متى تعمل |
|
||||
| -------------------------------- | -------------------------------------------------------------------------------------------- | ---------------------------------- |
|
||||
| `preflight` | اكتشاف تغييرات التوثيق فقط، والنطاقات المتغيرة، والامتدادات المتغيرة، وبناء بيان CI | دائمًا في عمليات الدفع وطلبات السحب غير المسودة |
|
||||
| `security-scm-fast` | اكتشاف المفاتيح الخاصة وتدقيق سير العمل عبر `zizmor` | دائمًا في عمليات الدفع وطلبات السحب غير المسودة |
|
||||
| `security-dependency-audit` | تدقيق ملف قفل الإنتاج دون اعتماديات مقابل تنبيهات npm | دائمًا في عمليات الدفع وطلبات السحب غير المسودة |
|
||||
| `security-fast` | تجميع مطلوب لمهام الأمان السريعة | دائمًا في عمليات الدفع وطلبات السحب غير المسودة |
|
||||
| `check-dependencies` | تمريرة Knip للإنتاج للاعتماديات فقط، مع حارس قائمة السماح للملفات غير المستخدمة | تغييرات ذات صلة بـ Node |
|
||||
| `build-artifacts` | بناء `dist/`، وواجهة Control UI، وفحوصات الآثار المبنية، وآثار قابلة لإعادة الاستخدام لاحقًا | تغييرات ذات صلة بـ Node |
|
||||
| `checks-fast-core` | مسارات صحة سريعة على Linux مثل فحوصات المضمن/عقد Plugin/البروتوكول | تغييرات ذات صلة بـ Node |
|
||||
| `checks-fast-contracts-channels` | فحوصات عقود القنوات المقسمة إلى أجزاء مع نتيجة فحص تجميعية ثابتة | تغييرات ذات صلة بـ Node |
|
||||
| `checks-node-core-test` | أجزاء اختبارات Node الأساسية، باستثناء مسارات القنوات والمضمن والعقود والامتدادات | تغييرات ذات صلة بـ Node |
|
||||
| `check` | مكافئ البوابة المحلية الرئيسية المقسمة: أنواع الإنتاج، والLint، والحراس، وأنواع الاختبار، وفحص smoke صارم | تغييرات ذات صلة بـ Node |
|
||||
| `check-additional` | أجزاء البنية، والحدود، وحراس سطح الامتدادات، وحدود الحزم، ومراقبة Gateway | تغييرات ذات صلة بـ Node |
|
||||
| `build-smoke` | اختبارات smoke لـ CLI المبني وفحص smoke لذاكرة بدء التشغيل | تغييرات ذات صلة بـ Node |
|
||||
| `checks` | متحقق لاختبارات قنوات الآثار المبنية | تغييرات ذات صلة بـ Node |
|
||||
| `checks-node-compat-node22` | مسار بناء وتحقق smoke للتوافق مع Node 22 | تشغيل CI يدوي للإصدارات |
|
||||
| `check-docs` | تنسيق التوثيق، والLint، وفحوصات الروابط المعطلة | عند تغير التوثيق |
|
||||
| `skills-python` | Ruff + pytest لـ Skills المدعومة بـ Python | تغييرات ذات صلة بـ Skills في Python |
|
||||
| `checks-windows` | اختبارات عمليات/مسارات خاصة بـ Windows إضافة إلى تراجعات محددات استيراد وقت التشغيل المشتركة | تغييرات ذات صلة بـ Windows |
|
||||
| `macos-node` | مسار اختبار TypeScript على macOS باستخدام الآثار المبنية المشتركة | تغييرات ذات صلة بـ macOS |
|
||||
| `macos-swift` | Swift lint والبناء والاختبارات لتطبيق macOS | تغييرات ذات صلة بـ macOS |
|
||||
| `android` | اختبارات وحدة Android لكلتا النكهتين إضافة إلى بناء APK واحد للتصحيح | تغييرات ذات صلة بـ Android |
|
||||
| `test-performance-agent` | تحسين يومي لاختبارات Codex البطيئة بعد نشاط موثوق | نجاح CI الرئيسي أو تشغيل يدوي |
|
||||
| `preflight` | اكتشاف تغييرات التوثيق فقط، والنطاقات المتغيرة، وPluginات المتغيرة، وبناء بيان CI | دائمًا عند الدفعات وطلبات السحب غير المسودة |
|
||||
| `security-scm-fast` | اكتشاف المفاتيح الخاصة وتدقيق سير العمل عبر `zizmor` | دائمًا عند الدفعات وطلبات السحب غير المسودة |
|
||||
| `security-dependency-audit` | تدقيق ملف قفل الإنتاج من دون تبعيات مقابل تحذيرات npm | دائمًا عند الدفعات وطلبات السحب غير المسودة |
|
||||
| `security-fast` | تجميع مطلوب لمهام الأمان السريعة | دائمًا عند الدفعات وطلبات السحب غير المسودة |
|
||||
| `check-dependencies` | تمريرة Knip للإنتاج الخاصة بالتبعيات فقط، إضافة إلى حارس قائمة السماح للملفات غير المستخدمة | تغييرات ذات صلة بـ Node |
|
||||
| `build-artifacts` | بناء `dist/`، وواجهة Control UI، وفحوصات القطع المبنية، والقطع القابلة لإعادة الاستخدام لاحقًا | تغييرات ذات صلة بـ Node |
|
||||
| `checks-fast-core` | مسارات صحة Linux السريعة مثل فحوصات الحزم المضمّنة/عقد Plugin/البروتوكول | تغييرات ذات صلة بـ Node |
|
||||
| `checks-fast-contracts-channels` | فحوصات عقود القنوات المقسمة إلى شظايا مع نتيجة تحقق تجميعية مستقرة | تغييرات ذات صلة بـ Node |
|
||||
| `checks-node-core-test` | شظايا اختبارات Node الأساسية، باستثناء مسارات القنوات والحزم المضمّنة والعقود وPluginات | تغييرات ذات صلة بـ Node |
|
||||
| `check` | مكافئ البوابة المحلية الرئيسية المقسمة إلى شظايا: أنواع الإنتاج، واللنت، والحراس، وأنواع الاختبارات، واختبار دخان صارم | تغييرات ذات صلة بـ Node |
|
||||
| `check-additional` | شظايا البنية المعمارية، والحدود، وحراس سطح Plugin، وحدود الحزم، ومراقبة Gateway | تغييرات ذات صلة بـ Node |
|
||||
| `build-smoke` | اختبارات دخان CLI المبني واختبار دخان ذاكرة بدء التشغيل | تغييرات ذات صلة بـ Node |
|
||||
| `checks` | متحقق لاختبارات قناة القطع المبنية | تغييرات ذات صلة بـ Node |
|
||||
| `checks-node-compat-node22` | مسار بناء ودخان للتوافق مع Node 22 | تشغيل CI يدوي للإصدارات |
|
||||
| `check-docs` | فحوصات تنسيق التوثيق واللنت والروابط المعطلة | عند تغير التوثيق |
|
||||
| `skills-python` | Ruff + pytest للـ Skills المدعومة بـ Python | تغييرات ذات صلة بـ Skills في Python |
|
||||
| `checks-windows` | اختبارات عمليات/مسارات خاصة بـ Windows إضافة إلى تراجعات محددات استيراد وقت التشغيل المشتركة | تغييرات ذات صلة بـ Windows |
|
||||
| `macos-node` | مسار اختبارات TypeScript على macOS باستخدام القطع المبنية المشتركة | تغييرات ذات صلة بـ macOS |
|
||||
| `macos-swift` | Swift lint وبناء واختبارات لتطبيق macOS | تغييرات ذات صلة بـ macOS |
|
||||
| `android` | اختبارات وحدة Android لكلا النكهتين إضافة إلى بناء APK تصحيحي واحد | تغييرات ذات صلة بـ Android |
|
||||
| `test-performance-agent` | تحسين يومي لاختبارات Codex البطيئة بعد نشاط موثوق | نجاح CI على main أو تشغيل يدوي |
|
||||
|
||||
## ترتيب الفشل السريع
|
||||
|
||||
1. يقرر `preflight` أي المسارات موجودة أصلًا. منطق `docs-scope` و`changed-scope` خطوات داخل هذه المهمة، وليسا مهمتين مستقلتين.
|
||||
2. تفشل `security-scm-fast` و`security-dependency-audit` و`security-fast` و`check` و`check-additional` و`check-docs` و`skills-python` بسرعة من دون انتظار مهام الآثار الأثقل ومصفوفة المنصات.
|
||||
3. يتداخل `build-artifacts` مع مسارات Linux السريعة كي يتمكن المستهلكون اللاحقون من البدء فور جاهزية البناء المشترك.
|
||||
4. تتوسع بعد ذلك مسارات المنصات ووقت التشغيل الأثقل: `checks-fast-core` و`checks-fast-contracts-channels` و`checks-node-core-test` و`checks` و`checks-windows` و`macos-node` و`macos-swift` و`android`.
|
||||
1. يقرر `preflight` أي المسارات موجودة أصلًا. منطق `docs-scope` و`changed-scope` خطوات داخل هذه المهمة، وليس مهام مستقلة.
|
||||
2. تفشل `security-scm-fast` و`security-dependency-audit` و`security-fast` و`check` و`check-additional` و`check-docs` و`skills-python` بسرعة من دون انتظار مهام القطع الأثقل ومصفوفة المنصات.
|
||||
3. يتداخل `build-artifacts` مع مسارات Linux السريعة حتى يتمكن المستهلكون اللاحقون من البدء فور جاهزية البناء المشترك.
|
||||
4. بعد ذلك تتوسع مسارات المنصات ووقت التشغيل الأثقل: `checks-fast-core` و`checks-fast-contracts-channels` و`checks-node-core-test` و`checks` و`checks-windows` و`macos-node` و`macos-swift` و`android`.
|
||||
|
||||
قد يعلّم GitHub المهام التي تجاوزها تشغيل أحدث على أنها `cancelled` عندما يصل دفع أحدث إلى طلب السحب نفسه أو مرجع `main`. تعامل مع ذلك كضجيج CI ما لم يكن أحدث تشغيل للمرجع نفسه يفشل أيضًا. تستخدم فحوصات الأجزاء التجميعية `!cancelled() && always()` بحيث تظل تبلغ عن إخفاقات الأجزاء العادية، لكنها لا تصطف بعد أن يكون سير العمل بأكمله قد تم تجاوزه بالفعل. مفتاح التزامن التلقائي لـ CI مُصدّر بإصدار (`CI-v7-*`) كي لا يستطيع تشغيل عالق من جهة GitHub في مجموعة صف قديمة حظر عمليات تشغيل main الأحدث إلى أجل غير مسمى. تستخدم عمليات تشغيل المجموعة الكاملة اليدوية `CI-manual-v1-*` ولا تلغي عمليات التشغيل الجارية.
|
||||
قد يضع GitHub علامة `cancelled` على المهام التي تجاوزها تشغيل أحدث عندما تصل دفعة أحدث إلى طلب السحب نفسه أو مرجع `main`. تعامل مع ذلك كضوضاء CI ما لم يكن أحدث تشغيل للمرجع نفسه يفشل أيضًا. تستخدم فحوصات الشظايا التجميعية `!cancelled() && always()` حتى تظل تبلّغ عن إخفاقات الشظايا العادية، لكنها لا تصطف في الطابور بعد أن يكون سير العمل بأكمله قد تجاوزه تشغيل أحدث. مفتاح تزامن CI التلقائي مُرقّم بإصدار (`CI-v7-*`) حتى لا يتمكن عالق من جهة GitHub في مجموعة طابور قديمة من حظر تشغيلات main الأحدث إلى أجل غير مسمى. تستخدم تشغيلات المجموعة الكاملة اليدوية `CI-manual-v1-*` ولا تلغي التشغيلات الجارية.
|
||||
|
||||
## النطاق والتوجيه
|
||||
|
||||
يقع منطق النطاق في `scripts/ci-changed-scope.mjs` وتغطيه اختبارات وحدة في `src/scripts/ci-changed-scope.test.ts`. يتجاوز التشغيل اليدوي اكتشاف النطاق المتغير ويجعل بيان preflight يتصرف كما لو أن كل منطقة محددة النطاق قد تغيرت.
|
||||
يوجد منطق النطاق في `scripts/ci-changed-scope.mjs` وتغطيه اختبارات وحدة في `src/scripts/ci-changed-scope.test.ts`. يتخطى التشغيل اليدوي اكتشاف النطاق المتغير ويجعل بيان preflight يتصرف كما لو أن كل منطقة ذات نطاق قد تغيرت.
|
||||
|
||||
- **تعديلات سير عمل CI** تتحقق من رسم CI البياني لـ Node إضافة إلى lint لسير العمل، لكنها لا تفرض وحدها بناءات Windows أو Android أو macOS الأصلية؛ تبقى مسارات المنصات هذه محددة بتغييرات مصادر المنصة.
|
||||
- **تعديلات توجيه CI فقط، وتعديلات تجهيزات اختبارات core رخيصة مختارة، وتعديلات مساعد/اختبار توجيه ضيقة لعقد Plugin** تستخدم مسار بيان سريع خاص بـ Node فقط: `preflight`، والأمان، ومهمة `checks-fast-core` واحدة. يتجاوز ذلك المسار آثار البناء، وتوافق Node 22، وعقود القنوات، وأجزاء core الكاملة، وأجزاء Plugin المضمنة، ومصفوفات الحراس الإضافية عندما يكون التغيير محدودًا بأسطح التوجيه أو المساعد التي تمارسها المهمة السريعة مباشرة.
|
||||
- **فحوصات Node على Windows** محددة بمغلفات العمليات/المسارات الخاصة بـ Windows، ومساعدات مشغّل npm/pnpm/UI، وإعداد مدير الحزم، وأسطح سير عمل CI التي تنفذ ذلك المسار؛ تبقى تغييرات المصدر وPlugin وinstall-smoke والاختبارات فقط غير ذات الصلة على مسارات Linux Node.
|
||||
- **تعديلات سير عمل CI** تتحقق من رسم CI الخاص بـ Node إضافة إلى لنت سير العمل، لكنها لا تفرض عمليات بناء Windows أو Android أو macOS الأصلية بذاتها؛ تبقى مسارات هذه المنصات محصورة في تغييرات مصدر المنصة.
|
||||
- **تعديلات توجيه CI فقط، وتعديلات مختارة لرُزم اختبارات أساسية رخيصة، وتعديلات ضيقة على مساعدي/توجيه اختبارات عقد Plugin** تستخدم مسار بيان سريعًا خاصًا بـ Node فقط: `preflight`، والأمان، ومهمة `checks-fast-core` واحدة. يتخطى ذلك المسار قطع البناء، وتوافق Node 22، وعقود القنوات، وشظايا الأساس الكاملة، وشظايا Pluginات المضمّنة، ومصفوفات الحراس الإضافية عندما يقتصر التغيير على أسطح التوجيه أو المساعدة التي تختبرها المهمة السريعة مباشرة.
|
||||
- **فحوصات Windows Node** محصورة في مغلفات العمليات/المسارات الخاصة بـ Windows، ومساعدي npm/pnpm/UI runner، وتكوين مدير الحزم، وأسطح سير عمل CI التي تنفذ ذلك المسار؛ تبقى تغييرات المصدر غير المرتبطة، وPlugin، ودخان التثبيت، وتغييرات الاختبارات فقط على مسارات Linux Node.
|
||||
|
||||
تُقسّم أو تُوازن أبطأ عائلات اختبارات Node بحيث تبقى كل مهمة صغيرة دون حجز زائد للمشغلات: تعمل عقود القنوات كثلاثة أجزاء موزونة، وتُقرن مسارات وحدات core الصغيرة، ويعمل auto-reply بأربعة عمال متوازنين (مع تقسيم الشجرة الفرعية للرد إلى أجزاء agent-runner وdispatch وcommands/state-routing)، وتُوزع إعدادات Gateway/Plugin الوكيلية عبر مهام Node الوكيلية القائمة الخاصة بالمصدر فقط بدل الانتظار على الآثار المبنية. تستخدم اختبارات المتصفح وQA والوسائط وPlugin المتنوعة الواسعة إعدادات Vitest المخصصة لها بدل مجمّع Plugin المشترك. تسجل أجزاء أنماط التضمين إدخالات التوقيت باستخدام اسم جزء CI، بحيث يمكن لـ `.artifacts/vitest-shard-timings.json` التمييز بين إعداد كامل وجزء مرشح. يُبقي `check-additional` عمل تجميع/Canary حدود الحزم معًا، ويفصل بنية طوبولوجيا وقت التشغيل عن تغطية مراقبة Gateway؛ ويشغّل جزء حارس الحدود حراسه الصغيرة المستقلة بالتوازي داخل مهمة واحدة. تعمل مراقبة Gateway، واختبارات القنوات، وجزء حدود دعم core بالتوازي داخل `build-artifacts` بعد بناء `dist/` و`dist-runtime/` بالفعل.
|
||||
تُقسّم أو تُوازن أبطأ عائلات اختبارات Node حتى تبقى كل مهمة صغيرة من دون حجز زائد للمشغلات: تعمل عقود القنوات كثلاث شظايا موزونة، وتُقرن مسارات الوحدات الأساسية الصغيرة، ويعمل الرد التلقائي كأربعة عمّال متوازنين (مع تقسيم شجرة الرد الفرعية إلى شظايا agent-runner وdispatch وcommands/state-routing)، وتُوزع تكوينات Gateway/Plugin الوكيلة عبر مهام Node الوكيلة الحالية الخاصة بالمصدر فقط بدلًا من انتظار القطع المبنية. تستخدم اختبارات المتصفح الواسعة، وQA، والوسائط، واختبارات Plugin المتنوعة تكوينات Vitest المخصصة لها بدلًا من مجمع Plugin المشترك العام. تسجل شظايا أنماط التضمين إدخالات توقيت باستخدام اسم شظية CI، حتى يستطيع `.artifacts/vitest-shard-timings.json` التمييز بين تكوين كامل وشظية مفلترة. يبقي `check-additional` عمل ترجمة/تجربة حدود الحزم معًا، ويفصل بنية طوبولوجيا وقت التشغيل عن تغطية مراقبة Gateway؛ تشغّل شظية حارس الحدود حراسها المستقلين الصغار بالتوازي داخل مهمة واحدة. تعمل مراقبة Gateway، واختبارات القنوات، وشظية حدود دعم الأساس بالتوازي داخل `build-artifacts` بعد أن يكون `dist/` و`dist-runtime/` قد بُنيا بالفعل.
|
||||
|
||||
يشغّل Android CI كلًا من `testPlayDebugUnitTest` و`testThirdPartyDebugUnitTest` ثم يبني Play debug APK. لا تملك نكهة الطرف الثالث مجموعة مصادر أو بيانًا منفصلًا؛ ما زال مسار اختبارات الوحدة الخاص بها يترجم النكهة مع أعلام BuildConfig الخاصة بـ SMS/call-log، مع تجنب مهمة تغليف debug APK مكررة في كل دفع ذي صلة بـ Android.
|
||||
تشغّل CI الخاصة بـ Android كلًا من `testPlayDebugUnitTest` و`testThirdPartyDebugUnitTest` ثم تبني APK التصحيحي لنكهة Play. لا تملك نكهة الطرف الثالث مجموعة مصدر أو بيانًا منفصلًا؛ ما زال مسار اختبارات الوحدة الخاص بها يترجم النكهة مع أعلام BuildConfig الخاصة بـ SMS/سجل المكالمات، مع تجنب مهمة تغليف APK تصحيحي مكررة عند كل دفعة ذات صلة بـ Android.
|
||||
|
||||
يشغّل جزء `check-dependencies` الأمر `pnpm deadcode:dependencies` (تمريرة Knip للإنتاج للاعتماديات فقط مثبتة على أحدث إصدار Knip، مع تعطيل الحد الأدنى لعمر إصدار pnpm لتثبيت `dlx`) و`pnpm deadcode:unused-files`، الذي يقارن نتائج Knip لملفات الإنتاج غير المستخدمة مع `scripts/deadcode-unused-files.allowlist.mjs`. يفشل حارس الملفات غير المستخدمة عندما يضيف طلب سحب ملفًا جديدًا غير مستخدم وغير مراجع، أو يترك إدخال قائمة سماح قديمًا، مع الحفاظ على أسطح Plugin الديناميكية المقصودة، والمولدة، والبناء، والاختبارات الحية، وجسور الحزم التي لا يستطيع Knip حلها ساكنًا.
|
||||
تشغّل شظية `check-dependencies` الأمر `pnpm deadcode:dependencies` (تمريرة Knip إنتاجية خاصة بالتبعيات فقط ومثبتة على أحدث إصدار من Knip، مع تعطيل حد العمر الأدنى لإصدار pnpm لتثبيت `dlx`) و`pnpm deadcode:unused-files`، الذي يقارن نتائج Knip الإنتاجية للملفات غير المستخدمة مع `scripts/deadcode-unused-files.allowlist.mjs`. يفشل حارس الملفات غير المستخدمة عندما يضيف طلب سحب ملفًا جديدًا غير مستخدم ولم يُراجع، أو يترك إدخالًا قديمًا في قائمة السماح، مع الحفاظ على أسطح Plugin الديناميكية المقصودة، والمولدة، والبناء، والاختبارات الحية، وجسور الحزم التي لا يستطيع Knip حلّها ساكنًا.
|
||||
|
||||
## عمليات التشغيل اليدوية
|
||||
## التشغيلات اليدوية
|
||||
|
||||
تشغّل عمليات CI اليدوية الرسم البياني نفسه للمهام مثل CI العادي، لكنها تفرض تشغيل كل مسار محدد النطاق غير Android: أجزاء Linux Node، وأجزاء Plugin المضمنة، وعقود القنوات، وتوافق Node 22، و`check`، و`check-additional`، وbuild smoke، وفحوصات التوثيق، وSkills في Python، وWindows، وmacOS، وControl UI i18n. تشغّل عمليات CI اليدوية المستقلة Android فقط مع `include_android=true`؛ وتمكّن مظلة الإصدار الكاملة Android بتمرير `include_android=true`. تُستثنى فحوصات Plugin الثابتة لما قبل الإصدار، وجزء `agentic-plugins` الخاص بالإصدار فقط، والمسح الدفعي الكامل للامتدادات، ومسارات Docker لما قبل إصدار Plugin من CI. لا تعمل مجموعة Docker لما قبل الإصدار إلا عندما يشغّل `Full Release Validation` سير عمل `Plugin Prerelease` المنفصل مع تمكين بوابة تحقق الإصدار.
|
||||
تشغّل عمليات CI اليدوية الرسم البياني نفسه للمهام مثل CI العادية، لكنها تفرض تشغيل كل مسار ذي نطاق غير Android: شظايا Linux Node، وشظايا Plugin المضمّنة، وعقود القنوات، وتوافق Node 22، و`check`، و`check-additional`، ودخان البناء، وفحوصات التوثيق، وSkills في Python، وWindows، وmacOS، وi18n لواجهة Control UI. تشغّل عمليات CI اليدوية المستقلة Android فقط مع `include_android=true`؛ وتفعّل مظلة الإصدار الكاملة Android بتمرير `include_android=true`. تُستبعد فحوصات Plugin prerelease الساكنة، وشظية `agentic-plugins` الخاصة بالإصدار فقط، ومسح دفعات Plugin الكامل، ومسارات Docker الخاصة بـ Plugin prerelease من CI. لا تعمل حزمة Docker prerelease إلا عندما يشغّل `Full Release Validation` سير عمل `Plugin Prerelease` المنفصل مع تمكين بوابة التحقق من الإصدار.
|
||||
|
||||
تستخدم عمليات التشغيل اليدوية مجموعة تزامن فريدة بحيث لا تلغي دفعة أخرى أو تشغيل طلب سحب على المرجع نفسه مجموعة كاملة لمرشح إصدار. يتيح إدخال `target_ref` الاختياري لمستدع موثوق تشغيل ذلك الرسم البياني على فرع أو وسم أو SHA كامل للالتزام مع استخدام ملف سير العمل من مرجع التشغيل المحدد.
|
||||
تستخدم التشغيلات اليدوية مجموعة تزامن فريدة حتى لا تُلغى المجموعة الكاملة لمرشح إصدار بواسطة دفعة أو تشغيل طلب سحب آخر على المرجع نفسه. يتيح إدخال `target_ref` الاختياري لمستدعٍ موثوق تشغيل ذلك الرسم البياني ضد فرع أو وسم أو SHA كامل للالتزام مع استخدام ملف سير العمل من مرجع التشغيل المحدد.
|
||||
|
||||
```bash
|
||||
gh workflow run ci.yml --ref release/YYYY.M.D
|
||||
@ -79,15 +79,15 @@ gh workflow run full-release-validation.yml --ref main -f ref=<branch-or-sha>
|
||||
|
||||
## المشغلات
|
||||
|
||||
| المشغّل | المهام |
|
||||
| المُشغّل | المهام |
|
||||
| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `ubuntu-24.04` | `preflight`، ومهام الأمان السريعة والتجميعات (`security-scm-fast`، `security-dependency-audit`، `security-fast`)، وفحوصات البروتوكول/العقد/المضمّنة السريعة، وفحوصات عقود القنوات المقسّمة، وأجزاء `check` باستثناء الفحص اللمطي، وأجزاء `check-additional` وتجميعاتها، ومحقّقات تجميع اختبارات Node، وفحوصات التوثيق، وSkills الخاصة بـ Python، وworkflow-sanity، وlabeler، وauto-response؛ يستخدم تمهيد install-smoke أيضا Ubuntu المستضاف على GitHub لكي تتمكن مصفوفة Blacksmith من الاصطفاف مبكرا |
|
||||
| `blacksmith-4vcpu-ubuntu-2404` | `CodeQL Critical Quality`، وأجزاء Plugin الأخف وزنا، و`checks-fast-core`، و`checks-node-compat-node22`، و`check-prod-types`، و`check-test-types` |
|
||||
| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`، وbuild-smoke، وأجزاء اختبار Linux Node، وأجزاء اختبار Plugin المضمّنة، و`android` |
|
||||
| `blacksmith-16vcpu-ubuntu-2404` | `check-lint` (حساس بما يكفي لاستهلاك CPU بحيث كلفت 8 vCPU أكثر مما وفرت)؛ وبنى Docker الخاصة بـ install-smoke (كلف وقت صف 32-vCPU أكثر مما وفر) |
|
||||
| `ubuntu-24.04` | `preflight`، ومهام الأمان السريعة والتجميعات (`security-scm-fast`، `security-dependency-audit`، `security-fast`)، وفحوصات البروتوكول/العقد/المضمّنة السريعة، وفحوصات عقود القنوات الموزعة، وشظايا `check` باستثناء lint، وشظايا `check-additional` وتجميعاتها، ومحققات تجميع اختبارات Node، وفحوصات الوثائق، وSkills الخاصة بـ Python، وworkflow-sanity، وlabeler، وauto-response؛ كما يستخدم تمهيد install-smoke Ubuntu المستضاف على GitHub بحيث يمكن لمصفوفة Blacksmith الاصطفاف أبكر |
|
||||
| `blacksmith-4vcpu-ubuntu-2404` | `CodeQL Critical Quality`، وشظايا Plugin الأقل وزنًا، و`checks-fast-core`، و`checks-node-compat-node22`، و`check-prod-types`، و`check-test-types` |
|
||||
| `blacksmith-8vcpu-ubuntu-2404` | `build-artifacts`، وbuild-smoke، وشظايا اختبارات Linux Node، وشظايا اختبارات Plugin المضمّنة، و`android` |
|
||||
| `blacksmith-16vcpu-ubuntu-2404` | `check-lint` (حساس للمعالج بما يكفي لأن 8 vCPU كلفت أكثر مما وفرت)؛ وبناءات Docker الخاصة بـ install-smoke (وقت الاصطفاف لـ 32-vCPU كلف أكثر مما وفر) |
|
||||
| `blacksmith-16vcpu-windows-2025` | `checks-windows` |
|
||||
| `blacksmith-6vcpu-macos-latest` | `macos-node` على `openclaw/openclaw`؛ تعود التفريعات إلى `macos-latest` |
|
||||
| `blacksmith-12vcpu-macos-latest` | `macos-swift` على `openclaw/openclaw`؛ تعود التفريعات إلى `macos-latest` |
|
||||
| `blacksmith-6vcpu-macos-latest` | `macos-node` على `openclaw/openclaw`؛ تعود الفروع المتشعبة إلى `macos-latest` |
|
||||
| `blacksmith-12vcpu-macos-latest` | `macos-swift` على `openclaw/openclaw`؛ تعود الفروع المتشعبة إلى `macos-latest` |
|
||||
|
||||
## المكافئات المحلية
|
||||
|
||||
@ -117,27 +117,27 @@ pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifac
|
||||
|
||||
## التحقق الكامل من الإصدار
|
||||
|
||||
`Full Release Validation` هو سير العمل اليدوي الجامع لـ "تشغيل كل شيء قبل الإصدار." يقبل فرعا أو وسما أو SHA كاملا للالتزام، ويشغّل سير عمل `CI` اليدوي بذلك الهدف، ويشغّل `Plugin Prerelease` لإثباتات Plugin/package/static/Docker الخاصة بالإصدار فقط، ويشغّل `OpenClaw Release Checks` لفحص التثبيت، وقبول الحزمة، ومجموعات مسار إصدار Docker، والاختبارات الحية/E2E، وOpenWebUI، وتكافؤ QA Lab، وMatrix، ومسارات Telegram. يمكنه أيضا تشغيل سير عمل `NPM Telegram Beta E2E` بعد النشر عند توفير مواصفة حزمة منشورة.
|
||||
`Full Release Validation` هو سير العمل اليدوي الجامع من أجل "تشغيل كل شيء قبل الإصدار". يقبل فرعًا أو وسمًا أو SHA كاملًا للالتزام، ويشغّل سير العمل اليدوي `CI` بذلك الهدف، ويشغّل `Plugin Prerelease` لإثباتات Plugin/الحزمة/الثابت/Docker الخاصة بالإصدار فقط، ويشغّل `OpenClaw Release Checks` لاختبار التثبيت، وقبول الحزمة، ومجموعات مسار إصدار Docker، والاختبارات الحية/E2E، وOpenWebUI، وتكافؤ QA Lab، وMatrix، ومسارات Telegram. ويمكنه أيضًا تشغيل سير العمل اللاحق للنشر `NPM Telegram Beta E2E` عند توفير مواصفة حزمة منشورة.
|
||||
|
||||
يتحكم `release_profile` في نطاق التغطية الحية/المزوّدين الممرر إلى فحوصات الإصدار:
|
||||
يتحكم `release_profile` في اتساع النطاق الحي/المزود الممرر إلى فحوصات الإصدار:
|
||||
|
||||
- يحافظ `minimum` على أسرع مسارات OpenAI/core الحرجة للإصدار.
|
||||
- يضيف `stable` مجموعة المزوّدين/الخلفيات المستقرة.
|
||||
- يشغّل `full` مصفوفة المزوّدين/الوسائط الاستشارية الواسعة.
|
||||
- يحافظ `minimum` على أسرع مسارات OpenAI/النواة الحرجة للإصدار.
|
||||
- يضيف `stable` مجموعة المزود/الخلفية المستقرة.
|
||||
- يشغّل `full` مصفوفة المزود/الوسائط الاستشارية الواسعة.
|
||||
|
||||
يسجل سير العمل الجامع معرّفات تشغيل الأبناء التي تم تشغيلها، وتعيد مهمة `Verify full validation` النهائية فحص استنتاجات تشغيل الأبناء الحالية وتلحق جداول أبطأ المهام لكل تشغيل ابن. إذا أعيد تشغيل سير عمل ابن وتحول إلى أخضر، فأعد تشغيل مهمة التحقق الأب فقط لتحديث نتيجة سير العمل الجامع وملخص التوقيت.
|
||||
يسجل سير العمل الجامع معرّفات تشغيل سلاسل العمل الفرعية التي شغّلها، وتعيد مهمة `Verify full validation` النهائية فحص الاستنتاجات الحالية لتشغيلات الأبناء وتلحق جداول أبطأ المهام لكل تشغيل ابن. إذا أُعيد تشغيل سير عمل فرعي وتحول إلى أخضر، فأعد تشغيل مهمة تحقق الأصل فقط لتحديث نتيجة المظلة وملخص التوقيت.
|
||||
|
||||
للاسترداد، يقبل كل من `Full Release Validation` و`OpenClaw Release Checks` قيمة `rerun_group`. استخدم `all` لمرشح إصدار، و`ci` للابن العادي الخاص بـ CI الكامل فقط، و`release-checks` لكل ابن إصدار، أو مجموعة أضيق: `install-smoke`، أو `cross-os`، أو `live-e2e`، أو `package`، أو `qa`، أو `qa-parity`، أو `qa-live`، أو `npm-telegram` على سير العمل الجامع. يبقي هذا إعادة تشغيل صندوق إصدار فاشل محدودة بعد إصلاح مركز.
|
||||
للاسترداد، يقبل كل من `Full Release Validation` و`OpenClaw Release Checks` القيمة `rerun_group`. استخدم `all` لمرشح إصدار، و`ci` لابن CI الكامل العادي فقط، و`release-checks` لكل ابن إصدار، أو مجموعة أضيق: `install-smoke`، أو `cross-os`، أو `live-e2e`، أو `package`، أو `qa`، أو `qa-parity`، أو `qa-live`، أو `npm-telegram` على سير العمل الجامع. وهذا يبقي إعادة تشغيل صندوق إصدار فاشل محدودة بعد إصلاح مركز.
|
||||
|
||||
تستخدم `OpenClaw Release Checks` مرجع سير العمل الموثوق لحل المرجع المحدد مرة واحدة إلى أرشيف `release-package-under-test`، ثم تمرر ذلك الأثر إلى كل من سير عمل Docker لمسار الإصدار الحي/E2E وجزء قبول الحزمة. يحافظ ذلك على اتساق بايتات الحزمة عبر صناديق الإصدار ويتجنب إعادة تغليف المرشح نفسه في عدة مهام أبناء.
|
||||
يستخدم `OpenClaw Release Checks` مرجع سير العمل الموثوق لحل المرجع المحدد مرة واحدة إلى أرشيف `release-package-under-test`، ثم يمرر ذلك الأثر إلى كل من سير عمل Docker لمسار الإصدار الحي/E2E وشظية قبول الحزمة. هذا يبقي بايتات الحزمة متسقة عبر صناديق الإصدار ويتجنب إعادة حزم المرشح نفسه في عدة مهام فرعية.
|
||||
|
||||
## الأجزاء الحية وأجزاء E2E
|
||||
## الشظايا الحية وE2E
|
||||
|
||||
يحافظ ابن الإصدار الحي/E2E على تغطية `pnpm test:live` الأصلية الواسعة، لكنه يشغلها كأجزاء مسماة عبر `scripts/test-live-shard.mjs` بدلا من مهمة تسلسلية واحدة:
|
||||
يبقي ابن الإصدار الحي/E2E تغطية `pnpm test:live` الأصلية الواسعة، لكنه يشغلها كشظايا مسماة عبر `scripts/test-live-shard.mjs` بدلًا من مهمة تسلسلية واحدة:
|
||||
|
||||
- `native-live-src-agents`
|
||||
- `native-live-src-gateway-core`
|
||||
- مهام `native-live-src-gateway-profiles` المفلترة حسب المزوّد
|
||||
- مهام `native-live-src-gateway-profiles` المفلترة حسب المزود
|
||||
- `native-live-src-gateway-backends`
|
||||
- `native-live-test`
|
||||
- `native-live-extensions-a-k`
|
||||
@ -145,57 +145,57 @@ pnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifac
|
||||
- `native-live-extensions-openai`
|
||||
- `native-live-extensions-o-z-other`
|
||||
- `native-live-extensions-xai`
|
||||
- أجزاء الصوت/الفيديو للوسائط المقسمة وأجزاء الموسيقى المفلترة حسب المزوّد
|
||||
- شظايا الصوت/الفيديو المقسمة وشظايا الموسيقى المفلترة حسب المزود
|
||||
|
||||
يحافظ ذلك على تغطية الملفات نفسها مع تسهيل إعادة تشغيل وتشخيص أعطال المزوّدين الحية البطيئة. تظل أسماء أجزاء التجميع `native-live-extensions-o-z`، و`native-live-extensions-media`، و`native-live-extensions-media-music` صالحة لإعادات التشغيل اليدوية لمرة واحدة.
|
||||
هذا يحافظ على تغطية الملفات نفسها مع جعل إخفاقات المزود الحي البطيئة أسهل في إعادة التشغيل والتشخيص. وتبقى أسماء الشظايا التجميعية `native-live-extensions-o-z` و`native-live-extensions-media` و`native-live-extensions-media-music` صالحة لإعادات التشغيل اليدوية ذات المحاولة الواحدة.
|
||||
|
||||
تعمل أجزاء الوسائط الحية الأصلية في `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`، المبني بواسطة سير عمل `Live Media Runner Image`. تثبّت تلك الصورة `ffmpeg` و`ffprobe` مسبقا؛ تتحقق مهام الوسائط من الثنائيات فقط قبل الإعداد. أبق مجموعات الاختبار الحية المدعومة بـ Docker على مشغّلات Blacksmith العادية، فمهام الحاويات ليست المكان الصحيح لتشغيل اختبارات Docker متداخلة.
|
||||
تعمل شظايا الوسائط الحية الأصلية في `ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04`، المبنية بواسطة سير عمل `Live Media Runner Image`. تثبت تلك الصورة مسبقًا `ffmpeg` و`ffprobe`؛ وتتحقق مهام الوسائط من الثنائيات فقط قبل الإعداد. أبقِ مجموعات الاختبارات الحية المدعومة بـ Docker على مشغّلات Blacksmith العادية — فمهام الحاويات ليست المكان المناسب لإطلاق اختبارات Docker المتداخلة.
|
||||
|
||||
تستخدم أجزاء النموذج/الخلفية الحية المدعومة بـ Docker صورة مشتركة منفصلة `ghcr.io/openclaw/openclaw-live-test:<sha>` لكل التزام محدد. يبني سير عمل الإصدار الحي تلك الصورة ويدفعها مرة واحدة، ثم تعمل أجزاء نموذج Docker الحي وGateway وخلفية CLI وربط ACP وحزمة Codex مع `OPENCLAW_SKIP_DOCKER_BUILD=1`. إذا أعادت تلك الأجزاء بناء هدف Docker الكامل من المصدر بشكل مستقل، فإعداد تشغيل الإصدار خاطئ وسيهدر وقتا فعليا على بنى صور مكررة.
|
||||
تستخدم شظايا النموذج/الخلفية الحية المدعومة بـ Docker صورة مشتركة منفصلة `ghcr.io/openclaw/openclaw-live-test:<sha>` لكل التزام محدد. يبني سير عمل الإصدار الحي تلك الصورة ويدفعها مرة واحدة، ثم تعمل شظايا نموذج Docker الحي، وGateway، وخلفية CLI، وربط ACP، وحزمة Codex مع `OPENCLAW_SKIP_DOCKER_BUILD=1`. إذا أعادت تلك الشظايا بناء هدف Docker الكامل للمصدر بشكل مستقل، فهذا يعني أن تشغيل الإصدار مهيأ بشكل خاطئ وسيهدر وقتًا فعليًا على بناءات صور مكررة.
|
||||
|
||||
## قبول الحزمة
|
||||
|
||||
استخدم `Package Acceptance` عندما يكون السؤال هو "هل تعمل حزمة OpenClaw القابلة للتثبيت هذه كمنتج؟" يختلف ذلك عن CI العادي: يتحقق CI العادي من شجرة المصدر، بينما يتحقق قبول الحزمة من أرشيف tarball واحد عبر حزمة Docker E2E نفسها التي يستخدمها المستخدمون بعد التثبيت أو التحديث.
|
||||
استخدم `Package Acceptance` عندما يكون السؤال هو "هل تعمل حزمة OpenClaw القابلة للتثبيت هذه كمنتج؟" وهو يختلف عن CI العادي: يتحقق CI العادي من شجرة المصدر، بينما يتحقق قبول الحزمة من أرشيف tarball واحد عبر حزمة Docker E2E نفسها التي يستخدمها المستخدمون بعد التثبيت أو التحديث.
|
||||
|
||||
### المهام
|
||||
|
||||
1. يسحب `resolve_package` `workflow_ref`، ويحل مرشح حزمة واحدا، ويكتب `.artifacts/docker-e2e-package/openclaw-current.tgz`، ويكتب `.artifacts/docker-e2e-package/package-candidate.json`، ويرفع كليهما كأثر `package-under-test`، ويطبع المصدر ومرجع سير العمل ومرجع الحزمة والإصدار وSHA-256 والملف الشخصي في ملخص خطوة GitHub.
|
||||
2. يستدعي `docker_acceptance` `openclaw-live-and-e2e-checks-reusable.yml` مع `ref=workflow_ref` و`package_artifact_name=package-under-test`. ينزّل سير العمل القابل لإعادة الاستخدام ذلك الأثر، ويتحقق من مخزون tarball، ويحضّر صور Docker الخاصة بملخص الحزمة عند الحاجة، ويشغّل مسارات Docker المحددة ضد تلك الحزمة بدلا من تغليف نسخة سير العمل المسحوبة. عندما يحدد ملف شخصي عدة `docker_lanes` موجهة، يجهز سير العمل القابل لإعادة الاستخدام الحزمة والصور المشتركة مرة واحدة، ثم يوزع تلك المسارات كمهام Docker موجهة متوازية مع آثار فريدة.
|
||||
3. يستدعي `package_telegram` اختياريا `NPM Telegram Beta E2E`. يعمل عندما لا يكون `telegram_mode` هو `none` ويثبت أثر `package-under-test` نفسه عندما يكون Package Acceptance قد حل واحدا؛ ولا يزال بإمكان تشغيل Telegram مستقل تثبيت مواصفة npm منشورة.
|
||||
4. تفشل `summary` سير العمل إذا فشل حل الحزمة، أو قبول Docker، أو مسار Telegram الاختياري.
|
||||
1. يتحقق `resolve_package` من `workflow_ref`، ويحل مرشح حزمة واحدًا، ويكتب `.artifacts/docker-e2e-package/openclaw-current.tgz`، ويكتب `.artifacts/docker-e2e-package/package-candidate.json`، ويرفع كليهما كأثر `package-under-test`، ويطبع المصدر، ومرجع سير العمل، ومرجع الحزمة، والإصدار، وSHA-256، والملف الشخصي في ملخص خطوة GitHub.
|
||||
2. يستدعي `docker_acceptance` الملف `openclaw-live-and-e2e-checks-reusable.yml` مع `ref=workflow_ref` و`package_artifact_name=package-under-test`. ينزل سير العمل القابل لإعادة الاستخدام ذلك الأثر، ويتحقق من جرد أرشيف tarball، ويجهز صور Docker الخاصة بملخص الحزمة عند الحاجة، ويشغل مسارات Docker المحددة ضد تلك الحزمة بدلًا من حزم نسخة سير العمل. عندما يحدد ملف شخصي عدة `docker_lanes` مستهدفة، يجهز سير العمل القابل لإعادة الاستخدام الحزمة والصور المشتركة مرة واحدة، ثم يوزع تلك المسارات كمهام Docker مستهدفة متوازية ذات آثار فريدة.
|
||||
3. يستدعي `package_telegram` اختياريًا `NPM Telegram Beta E2E`. يعمل عندما لا يكون `telegram_mode` هو `none` ويثبت أثر `package-under-test` نفسه عندما يكون قبول الحزمة قد حله؛ ولا يزال بإمكان تشغيل Telegram المستقل تثبيت مواصفة npm منشورة.
|
||||
4. يفشل `summary` سير العمل إذا فشل حل الحزمة، أو قبول Docker، أو مسار Telegram الاختياري.
|
||||
|
||||
### مصادر المرشحين
|
||||
|
||||
- يقبل `source=npm` فقط `openclaw@beta` أو `openclaw@latest` أو إصدار OpenClaw دقيقًا مثل `openclaw@2026.4.27-beta.2`. استخدم هذا لقبول الإصدارات التجريبية/المستقرة المنشورة.
|
||||
- يحزم `source=ref` فرعًا أو وسمًا أو SHA كاملًا موثوقًا من `package_ref`. يجلب المحلل فروع/وسوم OpenClaw، ويتحقق من أن الالتزام المحدد يمكن الوصول إليه من سجل فرع المستودع أو وسم إصدار، ويثبّت الاعتماديات في شجرة عمل منفصلة، ويحزمه باستخدام `scripts/package-openclaw-for-docker.mjs`.
|
||||
- يحمّل `source=url` ملف HTTPS بامتداد `.tgz`؛ يكون `package_sha256` مطلوبًا.
|
||||
- يحمّل `source=artifact` ملف `.tgz` واحدًا من `artifact_run_id` و`artifact_name`؛ يكون `package_sha256` اختياريًا لكن ينبغي توفيره للآثار المشتركة خارجيًا.
|
||||
- يحزم `source=ref` فرعًا أو وسمًا أو SHA كاملًا لالتزام `package_ref` موثوق. يجلب المحلّل فروع/وسوم OpenClaw، ويتحقق من أن الالتزام المحدد قابل للوصول من سجل فرع المستودع أو وسم إصدار، ثم يثبّت الاعتماديات في شجرة عمل منفصلة، ويحزمه باستخدام `scripts/package-openclaw-for-docker.mjs`.
|
||||
- ينزّل `source=url` ملف `.tgz` عبر HTTPS؛ يكون `package_sha256` مطلوبًا.
|
||||
- ينزّل `source=artifact` ملف `.tgz` واحدًا من `artifact_run_id` و`artifact_name`؛ يكون `package_sha256` اختياريًا، لكن ينبغي توفيره للقطع الأثرية المشتركة خارجيًا.
|
||||
|
||||
أبقِ `workflow_ref` و`package_ref` منفصلين. `workflow_ref` هو كود سير العمل/عدة الاختبار الموثوق الذي يشغّل الاختبار. `package_ref` هو التزام المصدر الذي يُحزم عندما يكون `source=ref`. يتيح هذا لعدة الاختبار الحالية التحقق من التزامات مصدر موثوقة أقدم دون تشغيل منطق سير عمل قديم.
|
||||
أبقِ `workflow_ref` و`package_ref` منفصلين. `workflow_ref` هو كود سير العمل/الحاضنة الموثوق الذي يشغّل الاختبار. `package_ref` هو التزام المصدر الذي يُحزّم عندما تكون القيمة `source=ref`. يتيح هذا لحاضنة الاختبار الحالية التحقق من التزامات مصدر موثوقة أقدم دون تشغيل منطق سير عمل قديم.
|
||||
|
||||
### ملفات تعريف المجموعة
|
||||
### ملفات تعريف الحزمة
|
||||
|
||||
- `smoke` — `npm-onboard-channel-agent`, `gateway-network`, `config-reload`
|
||||
- `package` — `npm-onboard-channel-agent`, `doctor-switch`, `update-channel-switch`, `bundled-channel-deps-compat`, `plugins-offline`, `plugin-update`
|
||||
- `package` — `npm-onboard-channel-agent`, `doctor-switch`, `update-channel-switch`, `upgrade-survivor`, `bundled-channel-deps-compat`, `plugins-offline`, `plugin-update`
|
||||
- `product` — `package` بالإضافة إلى `mcp-channels`, `cron-mcp-cleanup`, `openai-web-search-minimal`, `openwebui`
|
||||
- `full` — أجزاء مسار إصدار Docker الكاملة مع OpenWebUI
|
||||
- `custom` — `docker_lanes` الدقيقة؛ مطلوبة عندما يكون `suite_profile=custom`
|
||||
- `custom` — `docker_lanes` الدقيقة؛ مطلوبة عندما تكون `suite_profile=custom`
|
||||
|
||||
يستخدم ملف تعريف `package` تغطية Plugin بلا اتصال حتى لا يعتمد التحقق من الحزمة المنشورة على إتاحة ClawHub المباشرة. يعيد مسار Telegram الاختياري استخدام أثر `package-under-test` في `NPM Telegram Beta E2E`، مع إبقاء مسار مواصفة npm المنشورة للإرسال المستقل.
|
||||
يستخدم ملف تعريف `package` تغطية Plugin دون اتصال كي لا يكون التحقق من الحزمة المنشورة مشروطًا بتوافر ClawHub المباشر. يعيد مسار Telegram الاختياري استخدام قطعة `package-under-test` في `NPM Telegram Beta E2E`، مع إبقاء مسار مواصفة npm المنشورة لعمليات التشغيل المستقلة.
|
||||
|
||||
تستدعي فحوصات الإصدار Package Acceptance باستخدام `source=ref` و`package_ref=<release-ref>` و`workflow_ref=<release workflow ref>` و`suite_profile=custom` و`docker_lanes='bundled-channel-deps-compat plugins-offline'` و`telegram_mode=mock-openai`. تغطي أجزاء Docker لمسار الإصدار مسارات الحزمة/التحديث/Plugin المتداخلة؛ ويحافظ Package Acceptance على إثبات توافق القنوات المضمّنة الأصلي للأثر، وPlugin بلا اتصال، وTelegram، مقابل ملف tarball نفسه للحزمة المحلولة. لا تزال فحوصات الإصدار عبر أنظمة التشغيل تغطي الإعداد الأولي الخاص بنظام التشغيل، والمثبّت، وسلوك المنصة؛ وينبغي أن يبدأ تحقق منتج الحزمة/التحديث بـ Package Acceptance. تتحقق مسارات الحزمة والمثبّت الجديد على Windows أيضًا من أن الحزمة المثبتة يمكنها استيراد تجاوز تحكم بالمتصفح من مسار Windows مطلق خام. يستخدم اختبار دخان دورة وكيل OpenAI عبر أنظمة التشغيل `OPENCLAW_CROSS_OS_OPENAI_MODEL` افتراضيًا عند ضبطه، وإلا يستخدم `openai/gpt-5.4-mini`، حتى يبقى إثبات التثبيت وGateway سريعًا وحتميًا.
|
||||
تستدعي فحوصات الإصدار Package Acceptance باستخدام `source=ref` و`package_ref=<release-ref>` و`workflow_ref=<release workflow ref>` و`suite_profile=custom` و`docker_lanes='bundled-channel-deps-compat plugins-offline'` و`telegram_mode=mock-openai`. تغطي أجزاء Docker لمسار الإصدار مسارات الحزمة/التحديث/Plugin المتداخلة؛ وتحافظ Package Acceptance على إثبات توافق القنوات المضمنة الأصلي للقطعة، وPlugin دون اتصال، وTelegram مقابل أرشيف الحزمة نفسه الذي تم حله. ما زالت فحوصات الإصدار عبر أنظمة التشغيل تغطي الإعداد الأولي الخاص بنظام التشغيل، والمثبّت، وسلوك المنصة؛ ويجب أن يبدأ تحقق المنتج للحزمة/التحديث من Package Acceptance. تتحقق مسارات Windows المعبأة والمثبّت الجديد أيضًا من أن الحزمة المثبتة يمكنها استيراد تجاوز للتحكم في المتصفح من مسار Windows خام ومطلق. يعتمد اختبار الدخان لدورة وكيل OpenAI عبر أنظمة التشغيل افتراضيًا على `OPENCLAW_CROSS_OS_OPENAI_MODEL` عند ضبطه، وإلا يستخدم `openai/gpt-5.4-mini`، بحيث يبقى إثبات التثبيت وGateway سريعًا وحتميًا.
|
||||
|
||||
### نوافذ التوافق القديمة
|
||||
### نوافذ التوافق القديم
|
||||
|
||||
لدى Package Acceptance نوافذ توافق قديمة محدودة للحزم المنشورة مسبقًا. يمكن للحزم حتى `2026.4.25`، بما في ذلك `2026.4.25-beta.*`، استخدام مسار التوافق:
|
||||
تملك Package Acceptance نوافذ توافق قديم محدودة للحزم المنشورة مسبقًا. يمكن للحزم حتى `2026.4.25`، بما في ذلك `2026.4.25-beta.*`، استخدام مسار التوافق:
|
||||
|
||||
- قد تشير إدخالات QA الخاصة المعروفة في `dist/postinstall-inventory.json` إلى ملفات محذوفة من ملف tarball؛
|
||||
- قد تشير إدخالات QA الخاصة المعروفة في `dist/postinstall-inventory.json` إلى ملفات محذوفة من الأرشيف؛
|
||||
- قد يتخطى `doctor-switch` الحالة الفرعية لاستمرارية `gateway install --wrapper` عندما لا تعرض الحزمة ذلك العلم؛
|
||||
- قد يزيل `update-channel-switch` اعتماديات `pnpm.patchedDependencies` المفقودة من نموذج git الزائف المشتق من ملف tarball وقد يسجل فقدان `update.channel` المستمر؛
|
||||
- قد تقرأ اختبارات دخان Plugin مواقع سجل تثبيت قديمة أو تقبل فقدان استمرارية سجل تثبيت marketplace؛
|
||||
- قد يسمح `plugin-update` بترحيل بيانات وصف التكوين مع الاستمرار في اشتراط بقاء سجل التثبيت وسلوك عدم إعادة التثبيت دون تغيير.
|
||||
- قد يزيل `update-channel-switch` قيم `pnpm.patchedDependencies` المفقودة من تجهيزة git الوهمية المشتقة من الأرشيف، وقد يسجّل غياب `update.channel` المستمر؛
|
||||
- قد تقرأ اختبارات الدخان الخاصة بـ Plugin مواقع سجل تثبيت قديمة أو تقبل غياب استمرارية سجل تثبيت السوق؛
|
||||
- قد يسمح `plugin-update` بترحيل بيانات تعريف التهيئة مع استمرار اشتراط بقاء سجل التثبيت وسلوك عدم إعادة التثبيت دون تغيير.
|
||||
|
||||
قد تحذر حزمة `2026.4.26` المنشورة أيضًا من ملفات ختم بيانات وصف البناء المحلي التي شُحنت مسبقًا. يجب أن تستوفي الحزم اللاحقة العقود الحديثة؛ وتفشل الحالات نفسها بدلًا من التحذير أو التخطي.
|
||||
قد تحذر حزمة `2026.4.26` المنشورة أيضًا من ملفات ختم بيانات تعريف البناء المحلي التي كانت قد شُحنت بالفعل. يجب أن تفي الحزم اللاحقة بالعقود الحديثة؛ وتفشل الشروط نفسها بدلًا من التحذير أو التخطي.
|
||||
|
||||
### أمثلة
|
||||
|
||||
@ -238,111 +238,111 @@ gh workflow run package-acceptance.yml \
|
||||
-f docker_lanes='install-e2e plugin-update'
|
||||
```
|
||||
|
||||
عند تصحيح تشغيل Package Acceptance فاشل، ابدأ من ملخص `resolve_package` لتأكيد مصدر الحزمة وإصدارها وSHA-256. ثم افحص التشغيل الفرعي `docker_acceptance` وآثار Docker الخاصة به: `.artifacts/docker-tests/**/summary.json` و`failures.json` وسجلات المسارات وتوقيتات المراحل وأوامر إعادة التشغيل. فضّل إعادة تشغيل ملف تعريف الحزمة الفاشل أو مسارات Docker الدقيقة بدلًا من إعادة تشغيل تحقق الإصدار الكامل.
|
||||
عند تصحيح تشغيل فاشل لقبول الحزمة، ابدأ من ملخص `resolve_package` لتأكيد مصدر الحزمة وإصدارها وSHA-256. ثم افحص تشغيل الابن `docker_acceptance` وقطع Docker الأثرية الخاصة به: `.artifacts/docker-tests/**/summary.json` و`failures.json` وسجلات المسارات وتوقيتات المراحل وأوامر إعادة التشغيل. فضّل إعادة تشغيل ملف تعريف الحزمة الفاشل أو مسارات Docker الدقيقة بدلًا من إعادة تشغيل تحقق الإصدار الكامل.
|
||||
|
||||
## دخان التثبيت
|
||||
## اختبار دخان التثبيت
|
||||
|
||||
يعيد سير عمل `Install Smoke` المنفصل استخدام سكربت النطاق نفسه من خلال مهمة `preflight` الخاصة به. يقسم تغطية الدخان إلى `run_fast_install_smoke` و`run_full_install_smoke`.
|
||||
يعيد سير العمل المنفصل `Install Smoke` استخدام سكربت النطاق نفسه من خلال مهمة `preflight` الخاصة به. يقسم تغطية الدخان إلى `run_fast_install_smoke` و`run_full_install_smoke`.
|
||||
|
||||
- يشغّل **المسار السريع** لطلبات السحب التي تلمس أسطح Docker/الحزمة، أو تغييرات حزمة/بيان Plugin المضمّن، أو أسطح Plugin/القناة/Gateway/Plugin SDK الأساسية التي تمارسها وظائف دخان Docker. تغييرات Plugin المضمّن الخاصة بالمصدر فقط، وتعديلات الاختبارات فقط، وتعديلات الوثائق فقط لا تحجز عمال Docker. يبني المسار السريع صورة Dockerfile الجذرية مرة واحدة، ويفحص CLI، ويشغّل دخان CLI لحذف الوكلاء في مساحة العمل المشتركة، ويشغّل اختبار gateway-network e2e في الحاوية، ويتحقق من معامل بناء امتداد مضمّن، ويشغّل ملف تعريف Docker المحدود لـPlugin المضمّن ضمن مهلة إجمالية للأمر قدرها 240 ثانية (مع تحديد كل تشغيل Docker لكل سيناريو على حدة).
|
||||
- يبقي **المسار الكامل** تثبيت حزمة QR وتغطية Docker/التحديث للمثبّت للتشغيلات الليلية المجدولة، والإرسال اليدوي، وفحوصات إصدار workflow-call، وطلبات السحب التي تلمس فعلًا أسطح المثبّت/الحزمة/Docker. في الوضع الكامل، يجهز install-smoke صورة دخان GHCR مستهدفة لـSHA الحالي من Dockerfile الجذري أو يعيد استخدامها، ثم يشغّل تثبيت حزمة QR، ودخان Dockerfile/Gateway الجذري، ودخان المثبّت/التحديث، وDocker E2E السريع لـPlugin المضمّن كوظائف منفصلة حتى لا ينتظر عمل المثبّت خلف دخان الصورة الجذرية.
|
||||
- يشغّل **المسار السريع** لطلبات السحب التي تلمس أسطح Docker/الحزمة، أو تغييرات حزمة/بيان Plugin المضمنة، أو أسطح Plugin/القناة/Gateway/Plugin SDK الأساسية التي تمارسها مهام دخان Docker. لا تحجز تغييرات Plugin المصدرية المضمنة فقط، والتعديلات الخاصة بالاختبارات فقط، والتعديلات الخاصة بالتوثيق فقط، عمال Docker. يبني المسار السريع صورة Dockerfile الجذرية مرة واحدة، ويتحقق من CLI، ويشغّل اختبار دخان CLI لحذف الوكلاء من مساحة العمل المشتركة، ويشغّل اختبار e2e لشبكة Gateway داخل الحاوية، ويتحقق من وسيطة بناء لامتداد مضمن، ويشغّل ملف تعريف Docker المحدود لـ Plugin المضمنة ضمن مهلة أوامر إجمالية قدرها 240 ثانية (مع تحديد كل تشغيل Docker لكل سيناريو على حدة).
|
||||
- يحتفظ **المسار الكامل** بتثبيت حزمة QR وتغطية Docker/التحديث للمثبّت للتشغيلات الليلية المجدولة، وعمليات التشغيل اليدوية، وفحوصات الإصدار عبر workflow-call، وطلبات السحب التي تلمس فعلًا أسطح المثبّت/الحزمة/Docker. في الوضع الكامل، يجهز install-smoke أو يعيد استخدام صورة دخان Dockerfile جذرية من GHCR لهدف SHA واحد، ثم يشغّل تثبيت حزمة QR، واختبارات دخان Dockerfile/Gateway الجذرية، واختبارات دخان المثبّت/التحديث، وDocker E2E السريع لـ Plugin المضمنة كمهام منفصلة كي لا ينتظر عمل المثبّت خلف اختبارات دخان الصورة الجذرية.
|
||||
|
||||
لا تفرض دفعات `main` (بما فيها التزامات الدمج) المسار الكامل؛ عندما يطلب منطق نطاق التغيير تغطية كاملة عند الدفع، يحافظ سير العمل على دخان Docker السريع ويترك دخان التثبيت الكامل للتحقق الليلي أو تحقق الإصدار.
|
||||
لا تفرض دفعات `main` (بما في ذلك التزامات الدمج) المسار الكامل؛ عندما يطلب منطق النطاق المتغير تغطية كاملة عند دفعة، يحتفظ سير العمل بدخان Docker السريع ويترك دخان التثبيت الكامل للتحقق الليلي أو تحقق الإصدار.
|
||||
|
||||
يُحرس دخان مزود الصورة لتثبيت Bun العام البطيء بشكل منفصل عبر `run_bun_global_install_smoke`. يعمل على الجدول الليلي ومن سير عمل فحوصات الإصدار، ويمكن لإرسالات `Install Smoke` اليدوية الاشتراك فيه، لكن طلبات السحب ودفعات `main` لا تفعل ذلك. تحتفظ اختبارات QR وDocker للمثبّت بملفات Dockerfile الخاصة بها المركزة على التثبيت.
|
||||
يُحاط اختبار دخان موفر الصور لتثبيت Bun العام البطيء بشكل منفصل عبر `run_bun_global_install_smoke`. يعمل وفق الجدول الليلي ومن سير عمل فحوصات الإصدار، ويمكن لعمليات تشغيل `Install Smoke` اليدوية الاشتراك فيه، لكن طلبات السحب ودفعات `main` لا تفعل ذلك. تحتفظ اختبارات Docker الخاصة بـ QR والمثبّت بملفات Dockerfile الخاصة بها والمركزة على التثبيت.
|
||||
|
||||
## Docker E2E المحلي
|
||||
|
||||
يبني `pnpm test:docker:all` مسبقًا صورة اختبار مباشر مشتركة واحدة، ويحزم OpenClaw مرة واحدة كملف tarball من npm، ويبني صورتين مشتركتين من `scripts/e2e/Dockerfile`:
|
||||
يبني `pnpm test:docker:all` مسبقًا صورة اختبار مباشر مشتركة واحدة، ويحزم OpenClaw مرة واحدة كأرشيف npm، ويبني صورتين مشتركتين من `scripts/e2e/Dockerfile`:
|
||||
|
||||
- مشغّل Node/Git مجرد لمسارات المثبّت/التحديث/اعتماديات Plugin؛
|
||||
- صورة وظيفية تثبّت ملف tarball نفسه في `/app` لمسارات الوظائف العادية.
|
||||
- مشغّل Node/Git مجرد لمسارات المثبّت/التحديث/اعتمادية Plugin؛
|
||||
- صورة وظيفية تثبّت الأرشيف نفسه في `/app` لمسارات الوظائف العادية.
|
||||
|
||||
توجد تعريفات مسارات Docker في `scripts/lib/docker-e2e-scenarios.mjs`، ويقع منطق المخطط في `scripts/lib/docker-e2e-plan.mjs`، ولا ينفذ المشغّل إلا الخطة المحددة. يختار المجدول الصورة لكل مسار باستخدام `OPENCLAW_DOCKER_E2E_BARE_IMAGE` و`OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`، ثم يشغّل المسارات باستخدام `OPENCLAW_SKIP_DOCKER_BUILD=1`.
|
||||
توجد تعريفات مسارات Docker في `scripts/lib/docker-e2e-scenarios.mjs`، ويعيش منطق المخطط في `scripts/lib/docker-e2e-plan.mjs`، ولا ينفذ المشغّل إلا الخطة المحددة. يحدد المجدول الصورة لكل مسار باستخدام `OPENCLAW_DOCKER_E2E_BARE_IMAGE` و`OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE`، ثم يشغّل المسارات باستخدام `OPENCLAW_SKIP_DOCKER_BUILD=1`.
|
||||
|
||||
### القيم القابلة للضبط
|
||||
### المعاملات القابلة للضبط
|
||||
|
||||
| المتغير | الافتراضي | الغرض |
|
||||
| -------------------------------------- | ------- | --------------------------------------------------------------------------------------------- |
|
||||
| `OPENCLAW_DOCKER_ALL_PARALLELISM` | 10 | عدد خانات المجموعة الرئيسية للمسارات العادية. |
|
||||
| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10 | عدد خانات مجموعة الذيل الحساسة للمزود. |
|
||||
| `OPENCLAW_DOCKER_ALL_LIVE_LIMIT` | 9 | حد المسارات المباشرة المتزامنة حتى لا تخنق المزودات. |
|
||||
| `OPENCLAW_DOCKER_ALL_NPM_LIMIT` | 10 | حد مسارات تثبيت npm المتزامنة. |
|
||||
| `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT` | 7 | حد مسارات الخدمات المتعددة المتزامنة. |
|
||||
| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000 | التأخير بين بدايات المسارات لتجنب عواصف إنشاء Docker daemon؛ اضبطه على `0` لعدم التأخير. |
|
||||
| `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS` | 7200000 | مهلة احتياطية لكل مسار (120 دقيقة)؛ تستخدم مسارات مباشرة/ذيلية محددة حدودًا أضيق. |
|
||||
| `OPENCLAW_DOCKER_ALL_DRY_RUN` | غير مضبوط | يطبع `1` خطة المجدول دون تشغيل المسارات. |
|
||||
| `OPENCLAW_DOCKER_ALL_LANES` | غير مضبوط | قائمة مسارات دقيقة مفصولة بفواصل؛ تتخطى دخان التنظيف حتى يتمكن الوكلاء من إعادة إنتاج مسار فاشل واحد. |
|
||||
| المتغير | الافتراضي | الغرض |
|
||||
| -------------------------------------- | --------- | --------------------------------------------------------------------------------------------- |
|
||||
| `OPENCLAW_DOCKER_ALL_PARALLELISM` | 10 | عدد خانات التجمع الرئيسي للمسارات العادية. |
|
||||
| `OPENCLAW_DOCKER_ALL_TAIL_PARALLELISM` | 10 | عدد خانات تجمع الذيل الحساس للموفر. |
|
||||
| `OPENCLAW_DOCKER_ALL_LIVE_LIMIT` | 9 | حد المسارات المباشرة المتزامنة كي لا يقيّد الموفرون المعدل. |
|
||||
| `OPENCLAW_DOCKER_ALL_NPM_LIMIT` | 10 | حد مسارات تثبيت npm المتزامنة. |
|
||||
| `OPENCLAW_DOCKER_ALL_SERVICE_LIMIT` | 7 | حد مسارات الخدمات المتعددة المتزامنة. |
|
||||
| `OPENCLAW_DOCKER_ALL_START_STAGGER_MS` | 2000 | تباعد بين بدايات المسارات لتجنب عواصف إنشاء عفريت Docker؛ اضبط `0` لعدم التباعد. |
|
||||
| `OPENCLAW_DOCKER_ALL_LANE_TIMEOUT_MS` | 7200000 | مهلة احتياطية لكل مسار (120 دقيقة)؛ تستخدم مسارات مباشرة/ذيلية محددة حدودًا أضيق. |
|
||||
| `OPENCLAW_DOCKER_ALL_DRY_RUN` | غير مضبوط | يطبع `1` خطة المجدول دون تشغيل المسارات. |
|
||||
| `OPENCLAW_DOCKER_ALL_LANES` | غير مضبوط | قائمة دقيقة مفصولة بفواصل للمسارات؛ تتخطى دخان التنظيف كي يتمكن الوكلاء من إعادة إنتاج مسار فاشل واحد. |
|
||||
|
||||
يمكن لمسار أثقل من حده الفعال أن يبدأ مع ذلك من مجموعة فارغة، ثم يعمل بمفرده حتى يحرر السعة. تنفذ عملية التجميع المحلية فحوصات Docker المسبقة، وتزيل حاويات OpenClaw E2E القديمة، وتصدر حالة المسارات النشطة، وتحفظ توقيتات المسارات للترتيب من الأطول أولًا، وتتوقف افتراضيًا عن جدولة مسارات مجمعة جديدة بعد أول فشل.
|
||||
يمكن لمسار أثقل من سقفه الفعّال أن يبدأ مع ذلك من تجمع فارغ، ثم يعمل وحده حتى يحرر السعة. تنفذ التجميعة المحلية فحوصات مسبقة لـ Docker، وتزيل حاويات OpenClaw E2E القديمة، وتصدر حالة المسارات النشطة، وتحفظ توقيتات المسارات للترتيب من الأطول أولًا، وتتوقف افتراضيًا عن جدولة مسارات مجمعة جديدة بعد أول فشل.
|
||||
|
||||
### سير عمل مباشر/E2E قابل لإعادة الاستخدام
|
||||
|
||||
يسأل سير العمل المباشر/E2E القابل لإعادة الاستخدام `scripts/test-docker-all.mjs --plan-json` عن الحزمة ونوع الصورة والصورة المباشرة والمسار وتغطية بيانات الاعتماد المطلوبة. ثم يحول `scripts/docker-e2e.mjs` تلك الخطة إلى مخرجات GitHub وملخصات. إما أن يحزم OpenClaw عبر `scripts/package-openclaw-for-docker.mjs`، أو يحمّل أثر حزمة من التشغيل الحالي، أو يحمّل أثر حزمة من `package_artifact_run_id`؛ ويتحقق من مخزون ملف tarball؛ ويبني ويدفع صور GHCR Docker E2E العارية/الوظيفية الموسومة بملخص الحزمة عبر ذاكرة التخزين المؤقت لطبقات Docker من Blacksmith عندما تحتاج الخطة إلى مسارات ذات حزمة مثبتة؛ ويعيد استخدام مدخلات `docker_e2e_bare_image`/`docker_e2e_functional_image` المقدمة أو صور ملخص الحزمة الموجودة بدلًا من إعادة البناء. تُعاد محاولات سحب صور Docker بمهلة محدودة قدرها 180 ثانية لكل محاولة حتى يعيد تدفق سجل/ذاكرة تخزين مؤقت عالق المحاولة بسرعة بدلًا من استهلاك معظم المسار الحرج في CI.
|
||||
يسأل سير العمل المباشر/E2E القابل لإعادة الاستخدام `scripts/test-docker-all.mjs --plan-json` عن الحزمة ونوع الصورة والصورة المباشرة والمسار وتغطية بيانات الاعتماد المطلوبة. ثم يحول `scripts/docker-e2e.mjs` تلك الخطة إلى مخرجات وملخصات GitHub. إما أن يحزم OpenClaw عبر `scripts/package-openclaw-for-docker.mjs`، أو ينزّل قطعة حزمة من التشغيل الحالي، أو ينزّل قطعة حزمة من `package_artifact_run_id`؛ ويتحقق من مخزون الأرشيف؛ ويبني ويدفع صور Docker E2E المجردة/الوظيفية الموسومة بملخص الحزمة إلى GHCR من خلال ذاكرة التخزين المؤقت لطبقات Docker في Blacksmith عندما تحتاج الخطة إلى مسارات بحزمة مثبتة؛ ويعيد استخدام مدخلات `docker_e2e_bare_image`/`docker_e2e_functional_image` المقدمة أو صور ملخص الحزمة الموجودة بدلًا من إعادة البناء. تعاد محاولة سحب صور Docker بمهلة محدودة قدرها 180 ثانية لكل محاولة، بحيث تعاد محاولة دفق سجل/ذاكرة تخزين مؤقت عالق بسرعة بدلًا من استهلاك معظم المسار الحرج في CI.
|
||||
|
||||
### أجزاء مسار الإصدار
|
||||
|
||||
تعمل تغطية Docker للإصدار كوظائف أصغر مقسمة باستخدام `OPENCLAW_SKIP_DOCKER_BUILD=1` حتى يسحب كل جزء نوع الصورة الذي يحتاجه فقط وينفذ مسارات متعددة عبر المجدول الموزون نفسه:
|
||||
تعمل تغطية Docker للإصدار كمهام مجزأة أصغر باستخدام `OPENCLAW_SKIP_DOCKER_BUILD=1` بحيث يسحب كل جزء نوع الصورة الذي يحتاجه فقط وينفذ عدة مسارات عبر المجدول الموزون نفسه:
|
||||
|
||||
- `OPENCLAW_DOCKER_ALL_PROFILE=release-path`
|
||||
- `OPENCLAW_DOCKER_ALL_CHUNK=core | package-update-openai | package-update-anthropic | package-update-core | plugins-runtime-plugins | plugins-runtime-services | plugins-runtime-install-a..h | bundled-channels`
|
||||
|
||||
تجزئات Docker للإصدار الحالي هي `core` و`package-update-openai` و`package-update-anthropic` و`package-update-core` و`plugins-runtime-plugins` و`plugins-runtime-services` و`plugins-runtime-install-a` حتى `plugins-runtime-install-h` و`bundled-channels-core` و`bundled-channels-update-a` و`bundled-channels-update-discord` و`bundled-channels-update-b` و`bundled-channels-contracts`. تظل التجزئة التجميعية `bundled-channels` متاحة لإعادة التشغيل اليدوية لمرة واحدة، وتظل `plugins-runtime-core` و`plugins-runtime` و`plugins-integrations` أسماء مستعارة تجميعية للـ Plugin/وقت التشغيل. يظل الاسم المستعار للمسار `install-e2e` هو الاسم المستعار التجميعي لإعادة التشغيل اليدوية لكلا مساري تثبيت المزوّد. تشغّل تجزئة `bundled-channels` مسارات `bundled-channel-*` و`bundled-channel-update-*` المقسّمة بدلًا من مسار `bundled-channel-deps` التسلسلي الجامع.
|
||||
مقاطع Docker للإصدار الحالي هي `core` و`package-update-openai` و`package-update-anthropic` و`package-update-core` و`plugins-runtime-plugins` و`plugins-runtime-services` و`plugins-runtime-install-a` حتى `plugins-runtime-install-h` و`bundled-channels-core` و`bundled-channels-update-a` و`bundled-channels-update-discord` و`bundled-channels-update-b` و`bundled-channels-contracts`. يظل المقطع التجميعي `bundled-channels` متاحًا لإعادة التشغيل اليدوية لمرة واحدة، وتظل `plugins-runtime-core` و`plugins-runtime` و`plugins-integrations` أسماء مستعارة تجميعية للـ Plugin/وقت التشغيل. يظل الاسم المستعار للمسار `install-e2e` هو الاسم المستعار التجميعي لإعادة التشغيل اليدوية لكلا مساري مثبّت المزوّدين. يشغّل المقطع `bundled-channels` مسارات `bundled-channel-*` و`bundled-channel-update-*` المقسّمة بدلًا من المسار التسلسلي الشامل `bundled-channel-deps`.
|
||||
|
||||
يُضمّن OpenWebUI داخل `plugins-runtime-services` عندما تطلبه تغطية مسار الإصدار الكاملة، ويحتفظ بتجزئة مستقلة `openwebui` فقط لعمليات الإرسال الخاصة بـ OpenWebUI وحده. تعيد مسارات تحديث القنوات المضمّنة المحاولة مرة واحدة عند حدوث إخفاقات عابرة في شبكة npm.
|
||||
يُدمج OpenWebUI في `plugins-runtime-services` عندما تطلب تغطية مسار الإصدار الكامل ذلك، ويحتفظ بمقطع مستقل `openwebui` فقط لعمليات الإرسال الخاصة بـ OpenWebUI وحده. تعيد مسارات تحديث القنوات المضمّنة المحاولة مرة واحدة عند إخفاقات شبكة npm العابرة.
|
||||
|
||||
ترفع كل تجزئة `.artifacts/docker-tests/` مع سجلات المسارات، والتوقيتات، و`summary.json`، و`failures.json`، وتوقيتات المراحل، وJSON خطة المجدول، وجداول المسارات البطيئة، وأوامر إعادة التشغيل لكل مسار. يشغّل إدخال سير العمل `docker_lanes` المسارات المحددة مقابل الصور المُحضّرة بدلًا من وظائف التجزئة، ما يُبقي تصحيح المسار الفاشل محدودًا بوظيفة Docker واحدة مستهدفة، ويحضّر أو ينزّل أو يعيد استخدام أثر الحزمة لذلك التشغيل؛ إذا كان المسار المحدد مسار Docker حيًا، فإن الوظيفة المستهدفة تبني صورة الاختبار الحي محليًا لإعادة التشغيل تلك. تتضمن أوامر GitHub المُنشأة لإعادة التشغيل لكل مسار `package_artifact_run_id` و`package_artifact_name` ومدخلات الصور المُحضّرة عند وجود تلك القيم، بحيث يمكن لمسار فاشل إعادة استخدام الحزمة والصور نفسها من التشغيل الفاشل.
|
||||
يرفع كل مقطع `.artifacts/docker-tests/` متضمنًا سجلات المسارات، والتوقيتات، و`summary.json`، و`failures.json`، وتوقيتات المراحل، وملف JSON لخطة المجدول، وجداول المسارات البطيئة، وأوامر إعادة التشغيل لكل مسار. يشغّل إدخال سير العمل `docker_lanes` المسارات المحددة مقابل الصور المحضّرة بدلًا من وظائف المقاطع، مما يبقي تصحيح أخطاء المسارات الفاشلة محدودًا في وظيفة Docker واحدة مستهدفة، ويحضّر أثر الحزمة أو ينزّله أو يعيد استخدامه لذلك التشغيل؛ إذا كان المسار المحدد مسار Docker حيًا، تبني الوظيفة المستهدفة صورة الاختبار الحي محليًا لإعادة التشغيل تلك. تتضمن أوامر GitHub المولّدة لإعادة التشغيل لكل مسار `package_artifact_run_id` و`package_artifact_name` ومدخلات الصور المحضّرة عند وجود تلك القيم، بحيث يستطيع المسار الفاشل إعادة استخدام الحزمة والصور نفسها من التشغيل الفاشل.
|
||||
|
||||
```bash
|
||||
pnpm test:docker:rerun <run-id> # download Docker artifacts and print combined/per-lane targeted rerun commands
|
||||
pnpm test:docker:timings <summary> # slow-lane and phase critical-path summaries
|
||||
```
|
||||
|
||||
يشغّل سير العمل الحي/E2E المجدول مجموعة Docker الكاملة لمسار الإصدار يوميًا.
|
||||
يشغّل سير عمل live/E2E المجدول مجموعة Docker الكاملة لمسار الإصدار يوميًا.
|
||||
|
||||
## ما قبل إصدار Plugin
|
||||
## الإصدار التمهيدي للـ Plugin
|
||||
|
||||
`Plugin Prerelease` هو تغطية منتج/حزمة أعلى كلفة، لذلك فهو سير عمل منفصل يُرسل بواسطة `Full Release Validation` أو بواسطة مشغّل صريح. تُبقي طلبات السحب العادية، ودفعات `main`، وعمليات الإرسال اليدوية المستقلة لـ CI هذه المجموعة معطلة. يوازن اختبارات Plugin المضمّنة عبر ثمانية عمال امتدادات؛ وتشغّل وظائف تجزئة الامتدادات هذه ما يصل إلى مجموعتي تكوين Plugin في الوقت نفسه مع عامل Vitest واحد لكل مجموعة وذاكرة Node أكبر، حتى لا تنشئ دفعات Plugin كثيفة الاستيراد وظائف CI إضافية.
|
||||
`Plugin Prerelease` هو تغطية منتج/حزمة أعلى تكلفة، لذلك فهو سير عمل منفصل يُطلقه `Full Release Validation` أو مشغّل صريح. تبقي طلبات السحب العادية، ودفعات `main`، وعمليات إرسال CI اليدوية المستقلة، هذه المجموعة معطلة. يوازن اختبارات الـ Plugin المضمّنة عبر ثمانية عمال امتدادات؛ وتشغّل وظائف شظايا الامتدادات هذه ما يصل إلى مجموعتي إعداد Plugin في الوقت نفسه مع عامل Vitest واحد لكل مجموعة وحجم ذاكرة Node أكبر حتى لا تنشئ دفعات Plugin الثقيلة في الاستيراد وظائف CI إضافية.
|
||||
|
||||
## مختبر QA
|
||||
## مختبر ضمان الجودة
|
||||
|
||||
لمختبر QA مسارات CI مخصصة خارج سير العمل الرئيسي ذي النطاق الذكي.
|
||||
لدى مختبر ضمان الجودة مسارات CI مخصصة خارج سير العمل الرئيسي ذي النطاق الذكي.
|
||||
|
||||
- يعمل سير العمل `Parity gate` عند تغييرات PR المطابقة والإرسال اليدوي؛ فيبني وقت تشغيل QA الخاص ويقارن حزم الوكلاء الوظيفية الوهمية GPT-5.5 وOpus 4.6.
|
||||
- يعمل سير العمل `QA-Lab - All Lanes` كل ليلة على `main` وعند الإرسال اليدوي؛ ويوزّع بوابة التكافؤ الوهمية، ومسار Matrix الحي، ومساري Telegram وDiscord الحيين كوظائف متوازية. تستخدم الوظائف الحية بيئة `qa-live-shared`، ويستخدم Telegram/Discord عقود إيجار Convex.
|
||||
- يعمل سير العمل `Parity gate` عند تغييرات PR المطابقة وعند الإرسال اليدوي؛ فهو يبني وقت تشغيل ضمان الجودة الخاص ويقارن حزم الوكلاء الوهمية GPT-5.5 وOpus 4.6.
|
||||
- يعمل سير العمل `QA-Lab - All Lanes` ليلًا على `main` وعند الإرسال اليدوي؛ ويفرّع بوابة التكافؤ الوهمية، ومسار Matrix الحي، ومساري Telegram وDiscord الحيين كوظائف متوازية. تستخدم الوظائف الحية بيئة `qa-live-shared`، ويستخدم Telegram/Discord عقود Convex.
|
||||
|
||||
تشغّل فحوصات الإصدار مساري نقل Matrix وTelegram الحيين مع مزوّد وهمي حتمي ونماذج مؤهلة وهميًا (`mock-openai/gpt-5.5` و`mock-openai/gpt-5.5-alt`) بحيث يُعزل عقد القناة عن تأخر النموذج الحي وبدء تشغيل Plugin المزوّد العادي. يعطّل Gateway النقل الحي البحث في الذاكرة لأن تكافؤ QA يغطي سلوك الذاكرة بشكل منفصل؛ وتُغطى قابلية اتصال المزوّد بواسطة مجموعات النموذج الحي، والمزوّد الأصلي، ومزوّد Docker المنفصلة.
|
||||
تشغّل فحوصات الإصدار مساري النقل الحيين Matrix وTelegram باستخدام المزوّد الوهمي الحتمي والنماذج المؤهلة للوهم (`mock-openai/gpt-5.5` و`mock-openai/gpt-5.5-alt`) بحيث يكون عقد القناة معزولًا عن زمن استجابة النموذج الحي وبدء تشغيل Plugin المزوّد العادي. يعطل Gateway النقل الحي بحث الذاكرة لأن تكافؤ ضمان الجودة يغطي سلوك الذاكرة بشكل منفصل؛ وتغطي مجموعات النماذج الحية والمزوّدات الأصلية ومزوّدات Docker المنفصلة اتصال المزوّد.
|
||||
|
||||
يستخدم Matrix `--profile fast` للبوابات المجدولة وبوابات الإصدار، مع إضافة `--fail-fast` فقط عندما يدعمها CLI الذي تم سحبه. يظل الإعداد الافتراضي لـ CLI وإدخال سير العمل اليدوي `all`؛ ويجزّئ إرسال `matrix_profile=all` اليدوي دائمًا تغطية Matrix الكاملة إلى وظائف `transport` و`media` و`e2ee-smoke` و`e2ee-deep` و`e2ee-cli`.
|
||||
يستخدم Matrix الخيار `--profile fast` للبوابات المجدولة وبوابات الإصدار، مع إضافة `--fail-fast` فقط عندما يدعم CLI المستخرج ذلك. يظل الافتراضي في CLI وإدخال سير العمل اليدوي `all`؛ وتؤدي عملية إرسال `matrix_profile=all` اليدوية دائمًا إلى تقسيم تغطية Matrix الكاملة إلى وظائف `transport` و`media` و`e2ee-smoke` و`e2ee-deep` و`e2ee-cli`.
|
||||
|
||||
يشغّل `OpenClaw Release Checks` أيضًا مسارات مختبر QA الحرجة للإصدار قبل الموافقة على الإصدار؛ وتشغّل بوابة تكافؤ QA الخاصة به حزم المرشح والأساس كوظائف مسارات متوازية، ثم تنزّل كلا الأثرين إلى وظيفة تقرير صغيرة للمقارنة النهائية للتكافؤ.
|
||||
يشغّل `OpenClaw Release Checks` أيضًا مسارات مختبر ضمان الجودة الحرجة للإصدار قبل موافقة الإصدار؛ وتشغّل بوابة تكافؤ ضمان الجودة الخاصة به حزم المرشح والأساس كوظائف مسارات متوازية، ثم تنزّل كلا الأثرين إلى وظيفة تقرير صغيرة للمقارنة النهائية للتكافؤ.
|
||||
|
||||
لا تضع مسار هبوط PR خلف `Parity gate` إلا إذا كان التغيير يمس فعليًا وقت تشغيل QA، أو تكافؤ حزم النماذج، أو سطحًا يملكه سير عمل التكافؤ. بالنسبة لإصلاحات القنوات العادية، أو التكوين، أو الوثائق، أو اختبارات الوحدة، تعامل معه كإشارة اختيارية واتبع أدلة CI/الفحص ذات النطاق المحدد بدلًا من ذلك.
|
||||
لا تضع مسار دمج PR خلف `Parity gate` إلا إذا كان التغيير يمس فعليًا وقت تشغيل ضمان الجودة، أو تكافؤ حزم النماذج، أو سطحًا يملكه سير عمل التكافؤ. بالنسبة لإصلاحات القنوات أو الإعدادات أو الوثائق أو اختبارات الوحدة العادية، تعامل معه كإشارة اختيارية واتبع أدلة CI/الفحوصات ذات النطاق المحدد بدلًا من ذلك.
|
||||
|
||||
## CodeQL
|
||||
|
||||
سير العمل `CodeQL` هو ماسح أمان ضيق للمرور الأول عمدًا، وليس مسحًا كاملًا للمستودع. تفحص عمليات الحراسة اليومية واليدوية وطلبات السحب غير المسودة كود سير عمل Actions إضافة إلى أسطح JavaScript/TypeScript الأعلى خطرًا باستخدام استعلامات أمان عالية الثقة مفلترة إلى `security-severity` عالٍ/حرج.
|
||||
سير عمل `CodeQL` هو عمدًا ماسح أمان أولي ضيق النطاق، وليس مسحًا كاملًا للمستودع. تقوم عمليات الحراسة اليومية واليدوية وطلبات السحب غير المسودة بفحص كود سير عمل Actions إضافة إلى أعلى أسطح JavaScript/TypeScript خطورةً باستخدام استعلامات أمان عالية الثقة مرشحة إلى `security-severity` عالية/حرجة.
|
||||
|
||||
يبقى حارس طلب السحب خفيفًا: فهو يبدأ فقط للتغييرات تحت `.github/actions` أو`.github/codeql` أو`.github/workflows` أو`packages` أو`src`، ويشغّل مصفوفة الأمان عالية الثقة نفسها مثل سير العمل المجدول. يبقى CodeQL الخاص بـ Android وmacOS خارج الإعدادات الافتراضية لطلبات السحب.
|
||||
تظل حراسة طلب السحب خفيفة: فهي تبدأ فقط للتغييرات ضمن `.github/actions` أو `.github/codeql` أو `.github/workflows` أو `packages` أو `src`، وتشغّل مصفوفة الأمان عالية الثقة نفسها مثل سير العمل المجدول. يبقى Android وmacOS CodeQL خارج افتراضيات PR.
|
||||
|
||||
### فئات الأمان
|
||||
|
||||
| الفئة | السطح |
|
||||
| الفئة | السطح |
|
||||
| ------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `/codeql-security-high/core-auth-secrets` | المصادقة، الأسرار، الصندوق الرملي، Cron، وخط أساس Gateway |
|
||||
| `/codeql-security-high/channel-runtime-boundary` | عقود تنفيذ القناة الأساسية إضافة إلى وقت تشغيل Plugin القناة، وGateway، وPlugin SDK، والأسرار، ونقاط تماس التدقيق |
|
||||
| `/codeql-security-high/network-ssrf-boundary` | أسطح SSRF الأساسية، وتحليل IP، وحارس الشبكة، وجلب الويب، وسياسة SSRF في Plugin SDK |
|
||||
| `/codeql-security-high/mcp-process-tool-boundary` | خوادم MCP، ومساعدات تنفيذ العمليات، والتسليم الصادر، وبوابات تنفيذ أدوات الوكيل |
|
||||
| `/codeql-security-high/plugin-trust-boundary` | أسطح الثقة لتثبيت Plugin، والمحمّل، والبيان، والسجل، وتجهيز اعتماديات وقت التشغيل، وتحميل المصدر، وعقد حزمة Plugin SDK |
|
||||
| `/codeql-security-high/core-auth-secrets` | المصادقة والأسرار وبيئة العزل وCron وخط أساس Gateway |
|
||||
| `/codeql-security-high/channel-runtime-boundary` | عقود تنفيذ القنوات الأساسية إضافة إلى وقت تشغيل Plugin القنوات وGateway وPlugin SDK والأسرار ونقاط تدقيق المراجعة |
|
||||
| `/codeql-security-high/network-ssrf-boundary` | أسطح SSRF الأساسية وتحليل IP وحارس الشبكة وweb-fetch وسياسة SSRF في Plugin SDK |
|
||||
| `/codeql-security-high/mcp-process-tool-boundary` | خوادم MCP ومساعدات تنفيذ العمليات والتسليم الصادر وبوابات تنفيذ أدوات الوكيل |
|
||||
| `/codeql-security-high/plugin-trust-boundary` | أسطح ثقة تثبيت Plugin والمحمّل والبيان والسجل وتجهيز تبعيات وقت التشغيل وتحميل المصادر وعقد حزمة Plugin SDK |
|
||||
|
||||
### تجزئات أمان خاصة بالمنصة
|
||||
### شظايا الأمان الخاصة بالمنصات
|
||||
|
||||
- `CodeQL Android Critical Security` — تجزئة أمان Android مجدولة. تبني تطبيق Android يدويًا لـ CodeQL على أصغر مشغّل Blacksmith Linux تقبله سلامة سير العمل. ترفع تحت `/codeql-critical-security/android`.
|
||||
- `CodeQL macOS Critical Security` — تجزئة أمان macOS أسبوعية/يدوية. تبني تطبيق macOS يدويًا لـ CodeQL على Blacksmith macOS، وتفلتر نتائج بناء الاعتماديات من SARIF المرفوع، وترفع تحت `/codeql-critical-security/macos`. محفوظة خارج الإعدادات الافتراضية اليومية لأن بناء macOS يهيمن على وقت التشغيل حتى عندما يكون نظيفًا.
|
||||
- `CodeQL Android Critical Security` — شظية أمان Android مجدولة. تبني تطبيق Android يدويًا من أجل CodeQL على أصغر مشغّل Blacksmith Linux يقبله فحص سلامة سير العمل. ترفع ضمن `/codeql-critical-security/android`.
|
||||
- `CodeQL macOS Critical Security` — شظية أمان macOS أسبوعية/يدوية. تبني تطبيق macOS يدويًا من أجل CodeQL على Blacksmith macOS، وتصفّي نتائج بناء التبعيات من SARIF المرفوع، وترفع ضمن `/codeql-critical-security/macos`. تُبقى خارج الافتراضيات اليومية لأن بناء macOS يهيمن على وقت التشغيل حتى عندما يكون نظيفًا.
|
||||
|
||||
### فئات الجودة الحرجة
|
||||
|
||||
`CodeQL Critical Quality` هي التجزئة غير الأمنية المطابقة. تشغّل فقط استعلامات جودة JavaScript/TypeScript غير الأمنية وبشدة خطأ على أسطح ضيقة عالية القيمة على مشغّل Blacksmith Linux الأصغر. حارس طلب السحب الخاص بها أصغر عمدًا من الملف المجدول: لا تشغّل طلبات السحب غير المسودة إلا تجزئات `agent-runtime-boundary` و`config-boundary` و`core-auth-secrets` و`channel-runtime-boundary` و`gateway-runtime-boundary` و`memory-runtime-boundary` و`mcp-process-runtime-boundary` و`provider-runtime-boundary` و`session-diagnostics-boundary` و`plugin-boundary` و`plugin-sdk-package-contract` و`plugin-sdk-reply-runtime` المطابقة عند تغييرات كود تنفيذ أوامر/نماذج/أدوات الوكيل وإرسال الردود، أو كود مخطط/ترحيل/إدخال وإخراج التكوين، أو كود المصادقة/الأسرار/الصندوق الرملي/الأمان، أو وقت تشغيل القناة الأساسية وPlugin القناة المضمّنة، أو بروتوكول Gateway/طريقة الخادم، أو وقت تشغيل الذاكرة/ربط SDK، أو MCP/العمليات/التسليم الصادر، أو وقت تشغيل المزوّد/كتالوج النماذج، أو تشخيصات الجلسة/صفوف التسليم، أو محمّل Plugin، أو عقد حزمة Plugin SDK، أو وقت تشغيل رد Plugin SDK. تشغّل تغييرات تكوين CodeQL وسير عمل الجودة جميع تجزئات جودة PR الاثنتي عشرة.
|
||||
`CodeQL Critical Quality` هي الشظية غير الأمنية المقابلة. تشغّل فقط استعلامات جودة JavaScript/TypeScript غير الأمنية ذات شدة الخطأ على أسطح ضيقة عالية القيمة على مشغّل Blacksmith Linux الأصغر. حراسة طلب السحب الخاصة بها أصغر عمدًا من ملف التعريف المجدول: لا تشغّل طلبات السحب غير المسودة إلا شظايا `agent-runtime-boundary` و`config-boundary` و`core-auth-secrets` و`channel-runtime-boundary` و`gateway-runtime-boundary` و`memory-runtime-boundary` و`mcp-process-runtime-boundary` و`provider-runtime-boundary` و`session-diagnostics-boundary` و`plugin-boundary` و`plugin-sdk-package-contract` و`plugin-sdk-reply-runtime` المطابقة لتغييرات كود تنفيذ أوامر/نماذج/أدوات الوكيل وإرسال الردود، وكود مخطط/ترحيل/إدخال وإخراج الإعدادات، وكود المصادقة/الأسرار/العزل/الأمان، ووقت تشغيل القنوات الأساسية وPlugin القنوات المضمّنة، وبروتوكول Gateway/طريقة الخادم، ووقت تشغيل الذاكرة/ربط SDK، وMCP/العمليات/التسليم الصادر، ووقت تشغيل المزوّد/كتالوج النماذج، وتشخيصات الجلسة/صفوف التسليم، ومحمّل Plugin، وعقد حزمة Plugin SDK، أو تغييرات وقت تشغيل رد Plugin SDK. تشغّل تغييرات إعداد CodeQL وسير عمل الجودة جميع شظايا جودة PR الاثنتي عشرة.
|
||||
|
||||
يقبل الإرسال اليدوي:
|
||||
|
||||
@ -350,40 +350,40 @@ pnpm test:docker:timings <summary> # slow-lane and phase critical-path summari
|
||||
profile=all|agent-runtime-boundary|config-boundary|core-auth-secrets|channel-runtime-boundary|gateway-runtime-boundary|memory-runtime-boundary|mcp-process-runtime-boundary|plugin-boundary|plugin-sdk-package-contract|plugin-sdk-reply-runtime|provider-runtime-boundary|session-diagnostics-boundary
|
||||
```
|
||||
|
||||
الملفات الضيقة هي خطافات تعليم/تكرار لتشغيل تجزئة جودة واحدة بمعزل.
|
||||
ملفات التعريف الضيقة هي خطافات تعليم/تكرار لتشغيل شظية جودة واحدة بمعزل.
|
||||
|
||||
| الفئة | السطح |
|
||||
| ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `/codeql-critical-quality/core-auth-secrets` | المصادقة، والأسرار، وبيئة العزل، وcron، وكود حدود أمان Gateway |
|
||||
| `/codeql-critical-quality/core-auth-secrets` | المصادقة، والأسرار، وبيئة العزل، وCron، وكود حدود أمان Gateway |
|
||||
| `/codeql-critical-quality/config-boundary` | مخطط الإعدادات، والترحيل، والتطبيع، وعقود الإدخال/الإخراج |
|
||||
| `/codeql-critical-quality/gateway-runtime-boundary` | مخططات بروتوكول Gateway وعقود طرائق الخادم |
|
||||
| `/codeql-critical-quality/channel-runtime-boundary` | عقود تنفيذ القنوات الأساسية وPlugin القنوات المجمعة |
|
||||
| `/codeql-critical-quality/agent-runtime-boundary` | تنفيذ الأوامر، وتوجيه النماذج/الموفرين، وتوجيه الرد التلقائي والطوابير، وعقود وقت تشغيل مستوى تحكم ACP |
|
||||
| `/codeql-critical-quality/gateway-runtime-boundary` | مخططات بروتوكول Gateway وعقود أساليب الخادم |
|
||||
| `/codeql-critical-quality/channel-runtime-boundary` | عقود تنفيذ القنوات الأساسية وPlugin القناة المضمّنة |
|
||||
| `/codeql-critical-quality/agent-runtime-boundary` | تنفيذ الأوامر، وتوجيه النموذج/المزوّد، وتوجيه الرد التلقائي والطوابير، وعقود وقت تشغيل مستوى تحكم ACP |
|
||||
| `/codeql-critical-quality/mcp-process-runtime-boundary` | خوادم MCP وجسور الأدوات، ومساعدات الإشراف على العمليات، وعقود التسليم الصادر |
|
||||
| `/codeql-critical-quality/memory-runtime-boundary` | Memory host SDK، وواجهات وقت تشغيل الذاكرة، وأسماء SDK المستعارة لذاكرة Plugin، وطبقة ربط تفعيل وقت تشغيل الذاكرة، وأوامر طبيب الذاكرة |
|
||||
| `/codeql-critical-quality/session-diagnostics-boundary` | الأجزاء الداخلية لطابور الردود، وطوابير تسليم الجلسات، ومساعدات ربط/تسليم الجلسات الصادرة، وأسطح حزم أحداث/سجلات التشخيص، وعقود CLI لطبيب الجلسات |
|
||||
| `/codeql-critical-quality/plugin-sdk-reply-runtime` | توجيه الردود الواردة في Plugin SDK، ومساعدات حمولة الرد/تقسيمها إلى مقاطع/وقت التشغيل، وخيارات رد القناة، وطوابير التسليم، ومساعدات ربط الجلسات/السلاسل |
|
||||
| `/codeql-critical-quality/provider-runtime-boundary` | تطبيع فهرس النماذج، ومصادقة الموفرين واكتشافهم، وتسجيل وقت تشغيل الموفرين، وافتراضات/فهارس الموفرين، وسجلات الويب/البحث/الجلب/التضمين |
|
||||
| `/codeql-critical-quality/ui-control-plane` | تهيئة واجهة التحكم، والاستمرارية المحلية، وتدفقات تحكم Gateway، وعقود وقت تشغيل مستوى تحكم المهام |
|
||||
| `/codeql-critical-quality/web-media-runtime-boundary` | عقود وقت التشغيل لجلب/بحث الويب الأساسي، وإدخال/إخراج الوسائط، وفهم الوسائط، وتوليد الصور، وتوليد الوسائط |
|
||||
| `/codeql-critical-quality/plugin-boundary` | عقود المحمل، والسجل، والسطح العام، ونقطة دخول Plugin SDK |
|
||||
| `/codeql-critical-quality/plugin-sdk-package-contract` | مصدر Plugin SDK المنشور من جهة الحزمة ومساعدات عقود حزم Plugin |
|
||||
| `/codeql-critical-quality/memory-runtime-boundary` | SDK مضيف الذاكرة، وواجهات وقت تشغيل الذاكرة، وأسماء Plugin SDK المستعارة للذاكرة، ووصلة تفعيل وقت تشغيل الذاكرة، وأوامر طبيب الذاكرة |
|
||||
| `/codeql-critical-quality/session-diagnostics-boundary` | تفاصيل طابور الرد الداخلية، وطوابير تسليم الجلسات، ومساعدات ربط/تسليم الجلسات الصادرة، وأسطح حزم أحداث/سجلات التشخيص، وعقود CLI لطبيب الجلسات |
|
||||
| `/codeql-critical-quality/plugin-sdk-reply-runtime` | توجيه الردود الواردة في Plugin SDK، ومساعدات حمولة الرد/تجزئته/وقت تشغيله، وخيارات رد القناة، وطوابير التسليم، ومساعدات ربط الجلسات/الخيوط |
|
||||
| `/codeql-critical-quality/provider-runtime-boundary` | تطبيع كتالوج النماذج، ومصادقة المزوّد واكتشافه، وتسجيل وقت تشغيل المزوّد، وافتراضات/كتالوجات المزوّد، وسجلات الويب/البحث/الجلب/التضمين |
|
||||
| `/codeql-critical-quality/ui-control-plane` | تمهيد واجهة التحكم، والاستمرارية المحلية، وتدفقات تحكم Gateway، وعقود وقت تشغيل مستوى تحكم المهام |
|
||||
| `/codeql-critical-quality/web-media-runtime-boundary` | جلب/بحث الويب الأساسي، وإدخال/إخراج الوسائط، وفهم الوسائط، وتوليد الصور، وعقود وقت تشغيل توليد الوسائط |
|
||||
| `/codeql-critical-quality/plugin-boundary` | عقود المُحمّل، والسجل، والسطح العام، ونقطة دخول Plugin SDK |
|
||||
| `/codeql-critical-quality/plugin-sdk-package-contract` | مصدر Plugin SDK المنشور من جانب الحزمة ومساعدات عقد حزمة Plugin |
|
||||
|
||||
تبقى الجودة منفصلة عن الأمان حتى يمكن جدولة نتائج الجودة أو قياسها أو تعطيلها أو توسيعها دون حجب إشارة الأمان. يجب إعادة إضافة توسيع CodeQL الخاص بـ Swift وPython وPlugin المجمعة كعمل متابعة محدود النطاق أو مقسم فقط بعد أن تستقر الملفات الشخصية الضيقة من حيث وقت التشغيل والإشارة.
|
||||
تبقى الجودة منفصلة عن الأمان بحيث يمكن جدولة نتائج الجودة أو قياسها أو تعطيلها أو توسيعها دون إخفاء إشارة الأمان. يجب إعادة إضافة توسعة CodeQL الخاصة بـ Swift وPython وPlugin المضمّنة كعمل متابعة محدود النطاق أو مجزأ فقط بعد أن تستقر الملفات الشخصية الضيقة في وقت التشغيل والإشارة.
|
||||
|
||||
## سير عمل الصيانة
|
||||
|
||||
### Docs Agent
|
||||
### وكيل المستندات
|
||||
|
||||
سير عمل `Docs Agent` هو مسار صيانة Codex مدفوع بالأحداث للحفاظ على توافق الوثائق الحالية مع التغييرات التي هبطت مؤخرًا. لا يملك جدولًا زمنيًا خالصًا: يمكن لتشغيل CI ناجح بدفعة غير آلية على `main` أن يشغله، ويمكن للتشغيل اليدوي تشغيله مباشرة. تتخطى استدعاءات تشغيل سير العمل عندما يكون `main` قد تقدم أو عندما يكون تشغيل آخر غير متخطى لـ Docs Agent قد أُنشئ خلال الساعة الماضية. عند تشغيله، يراجع نطاق الالتزامات من SHA المصدر السابق غير المتخطى لـ Docs Agent إلى `main` الحالي، لذا يمكن لتشغيل واحد كل ساعة أن يغطي كل تغييرات main المتراكمة منذ آخر تمرير للوثائق.
|
||||
سير عمل `Docs Agent` هو مسار صيانة Codex مدفوع بالأحداث لإبقاء المستندات الحالية متوافقة مع التغييرات التي وصلت مؤخرًا. ليس له جدول صرف: يمكن لتشغيل CI ناجح من دفع غير آلي على `main` أن يفعّله، ويمكن للتشغيل اليدوي تشغيله مباشرة. تتخطى استدعاءات تشغيل سير العمل عندما يكون `main` قد تقدّم أو عندما يكون تشغيل آخر غير متخطى لـ Docs Agent قد أُنشئ في الساعة الأخيرة. عند تشغيله، يراجع نطاق الالتزام من SHA مصدر Docs Agent السابق غير المتخطى إلى `main` الحالي، بحيث يمكن لتشغيل واحد كل ساعة أن يغطي كل تغييرات main المتراكمة منذ آخر مرور على المستندات.
|
||||
|
||||
### Test Performance Agent
|
||||
### وكيل أداء الاختبارات
|
||||
|
||||
سير عمل `Test Performance Agent` هو مسار صيانة Codex مدفوع بالأحداث للاختبارات البطيئة. لا يملك جدولًا زمنيًا خالصًا: يمكن لتشغيل CI ناجح بدفعة غير آلية على `main` أن يشغله، لكنه يتخطى إذا كان استدعاء تشغيل سير عمل آخر قد شُغّل أو قيد التشغيل في ذلك اليوم بتوقيت UTC. يتجاوز التشغيل اليدوي بوابة النشاط اليومية تلك. ينشئ المسار تقرير أداء Vitest مجمعًا للمجموعة الكاملة، ويسمح لـ Codex بإجراء إصلاحات أداء اختبار صغيرة تحافظ على التغطية فقط بدلًا من إعادة هيكلة واسعة، ثم يعيد تشغيل تقرير المجموعة الكاملة ويرفض التغييرات التي تقلل عدد اختبارات خط الأساس الناجحة. إذا كان لدى خط الأساس اختبارات فاشلة، يمكن لـ Codex إصلاح الإخفاقات الواضحة فقط، ويجب أن ينجح تقرير المجموعة الكاملة بعد الوكيل قبل الالتزام بأي شيء. عندما يتقدم `main` قبل هبوط دفعة البوت، يعيد المسار بناء التصحيح المتحقق منه فوقه، ويعيد تشغيل `pnpm check:changed`، ويحاول الدفع مجددًا؛ ويتم تخطي التصحيحات القديمة المتعارضة. يستخدم Ubuntu المستضاف على GitHub حتى يتمكن إجراء Codex من الحفاظ على وضع أمان إسقاط sudo نفسه مثل وكيل الوثائق.
|
||||
سير عمل `Test Performance Agent` هو مسار صيانة Codex مدفوع بالأحداث للاختبارات البطيئة. ليس له جدول صرف: يمكن لتشغيل CI ناجح من دفع غير آلي على `main` أن يفعّله، لكنه يتخطى إذا كان استدعاء تشغيل سير عمل آخر قد عمل بالفعل أو يعمل في ذلك اليوم بتوقيت UTC. يتجاوز التشغيل اليدوي بوابة النشاط اليومية تلك. يبني المسار تقرير أداء Vitest مجمّعًا للمجموعة الكاملة، ويسمح لـ Codex بإجراء إصلاحات صغيرة فقط لأداء الاختبارات مع الحفاظ على التغطية بدلًا من إعادة هيكلة واسعة، ثم يعيد تشغيل تقرير المجموعة الكاملة ويرفض التغييرات التي تقلل عدد اختبارات خط الأساس الناجحة. إذا كان في خط الأساس اختبارات فاشلة، يجوز لـ Codex إصلاح الإخفاقات الواضحة فقط، ويجب أن ينجح تقرير المجموعة الكاملة بعد الوكيل قبل الالتزام بأي شيء. عندما يتقدم `main` قبل وصول دفع الروبوت، يعيد المسار إسناد التصحيح المتحقق منه، ويعيد تشغيل `pnpm check:changed`، ويعيد محاولة الدفع؛ ويتم تخطي التصحيحات القديمة المتعارضة. يستخدم Ubuntu المستضاف على GitHub حتى يتمكن إجراء Codex من الحفاظ على وضع أمان إسقاط sudo نفسه مثل وكيل المستندات.
|
||||
|
||||
### PRs مكررة بعد الدمج
|
||||
### طلبات PR المكررة بعد الدمج
|
||||
|
||||
سير عمل `Duplicate PRs After Merge` هو سير عمل يدوي للمشرفين لتنظيف التكرارات بعد الهبوط. افتراضيًا يعمل كتجربة جافة ولا يغلق إلا PRs المدرجة صراحة عندما تكون `apply=true`. قبل تعديل GitHub، يتحقق من أن PR الذي هبط مدمج وأن كل تكرار لديه إما مشكلة مرجعية مشتركة أو مقاطع تغييرات متداخلة.
|
||||
سير عمل `Duplicate PRs After Merge` هو سير عمل يدوي للمشرفين لتنظيف التكرارات بعد الوصول. يستخدم افتراضيًا التشغيل الجاف ولا يغلق إلا طلبات PR المدرجة صراحة عندما تكون `apply=true`. قبل تعديل GitHub، يتحقق من أن طلب PR الذي وصل مدمج وأن كل تكرار لديه إما مشكلة مرجعية مشتركة أو مقاطع تغييرات متداخلة.
|
||||
|
||||
```bash
|
||||
gh workflow run duplicate-after-merge.yml \
|
||||
@ -392,29 +392,29 @@ gh workflow run duplicate-after-merge.yml \
|
||||
-f apply=true
|
||||
```
|
||||
|
||||
## بوابات الفحص المحلية وتوجيه التغييرات
|
||||
## بوابات الفحص المحلي وتوجيه التغييرات
|
||||
|
||||
تعيش منطقية مسارات التغييرات المحلية في `scripts/changed-lanes.mjs` وتنفذها `scripts/check-changed.mjs`. بوابة الفحص المحلية هذه أكثر صرامة بشأن حدود المعمارية من نطاق منصة CI الواسع:
|
||||
توجد منطقية مسارات التغييرات المحلية في `scripts/changed-lanes.mjs` وتُنفذ بواسطة `scripts/check-changed.mjs`. بوابة الفحص المحلي هذه أكثر صرامة بشأن حدود البنية من نطاق منصة CI الواسع:
|
||||
|
||||
- تشغّل تغييرات الإنتاج الأساسية فحص أنواع إنتاج النواة واختبار النواة إضافة إلى فحص lint/الحراس للنواة؛
|
||||
- تشغّل تغييرات الاختبارات الأساسية فقط فحص أنواع اختبار النواة إضافة إلى فحص lint للنواة؛
|
||||
- تشغّل تغييرات إنتاج الإضافات فحص أنواع إنتاج الإضافة واختبار الإضافة إضافة إلى فحص lint للإضافة؛
|
||||
- تشغّل تغييرات اختبارات الإضافات فقط فحص أنواع اختبار الإضافة إضافة إلى فحص lint للإضافة؛
|
||||
- تتوسع تغييرات Plugin SDK العامة أو عقود Plugin إلى فحص أنواع الإضافات لأن الإضافات تعتمد على عقود النواة هذه (تبقى عمليات مسح امتدادات Vitest عمل اختبار صريحًا)؛
|
||||
- تشغّل زيادات الإصدار الخاصة ببيانات الإصدار فقط فحوصات موجّهة للإصدار/الإعدادات/اعتماديات الجذر؛
|
||||
- تفشل تغييرات الجذر/الإعدادات غير المعروفة بأمان إلى كل مسارات الفحص.
|
||||
- تغييرات الإنتاج الأساسية تشغّل فحص أنواع إنتاج الأساس واختباراته بالإضافة إلى فحص الأنماط/الحراس الأساسية؛
|
||||
- تغييرات الاختبارات الأساسية فقط تشغّل فقط فحص أنواع الاختبارات الأساسية بالإضافة إلى فحص الأنماط الأساسي؛
|
||||
- تغييرات إنتاج الإضافة تشغّل فحص أنواع إنتاج الإضافة واختباراتها بالإضافة إلى فحص أنماط الإضافة؛
|
||||
- تغييرات اختبارات الإضافة فقط تشغّل فحص أنواع اختبارات الإضافة بالإضافة إلى فحص أنماط الإضافة؛
|
||||
- تغييرات Plugin SDK العامة أو عقد Plugin تتوسع إلى فحص أنواع الإضافات لأن الإضافات تعتمد على تلك العقود الأساسية (تبقى عمليات مسح إضافات Vitest عمل اختبار صريحًا)؛
|
||||
- زيادات الإصدارات الخاصة ببيانات الإصدار الوصفية فقط تشغّل فحوصات مستهدفة للإصدار/الإعدادات/اعتماديات الجذر؛
|
||||
- تغييرات الجذر/الإعدادات غير المعروفة تفشل بأمان إلى جميع مسارات الفحص.
|
||||
|
||||
يعيش توجيه الاختبارات المحلية المتغيرة في `scripts/test-projects.test-support.mjs` وهو أرخص عمدًا من `check:changed`: تعديلات الاختبارات المباشرة تشغّل نفسها، وتفضل تعديلات المصدر الخرائط الصريحة، ثم اختبارات الأشقاء والتابعين في مخطط الاستيراد. إعداد تسليم غرف المجموعات المشتركة هو أحد الخرائط الصريحة: تمر التغييرات في إعداد الرد المرئي للمجموعة، أو وضع تسليم رد المصدر، أو مسار موجه النظام لأداة الرسائل عبر اختبارات الرد الأساسية إضافة إلى انحدارات تسليم Discord وSlack بحيث يفشل تغيير افتراضي مشترك قبل أول دفع PR. استخدم `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` فقط عندما يكون التغيير واسعًا على مستوى عدة الاختبار بما يكفي لأن المجموعة الرخيصة المعينة ليست بديلًا موثوقًا.
|
||||
يوجد توجيه الاختبارات المحلية المتغيرة في `scripts/test-projects.test-support.mjs` وهو أرخص عمدًا من `check:changed`: تعديلات الاختبارات المباشرة تشغّل نفسها، وتفضّل تعديلات المصدر الخرائط الصريحة، ثم الاختبارات الشقيقة والمعتمدين عبر مخطط الاستيراد. إعداد تسليم غرفة المجموعة المشتركة أحد الخرائط الصريحة: تغييرات إعداد الرد المرئي للمجموعة، أو وضع تسليم رد المصدر، أو موجّه النظام لأداة الرسائل تمر عبر اختبارات الرد الأساسية بالإضافة إلى انحدارات تسليم Discord وSlack حتى يفشل تغيير افتراضي مشترك قبل أول دفع PR. استخدم `OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed` فقط عندما يكون التغيير واسعًا على مستوى الحاضنة بما يكفي بحيث لا تكون المجموعة الرخيصة المرسومة وكيلًا موثوقًا.
|
||||
|
||||
## التحقق عبر Testbox
|
||||
## تحقق Testbox
|
||||
|
||||
شغّل Testbox من جذر المستودع وفضّل صندوقًا جديدًا دافئًا لإثبات واسع. قبل إنفاق بوابة بطيئة على صندوق أُعيد استخدامه أو انتهت صلاحيته أو أبلغ للتو عن مزامنة كبيرة على نحو غير متوقع، شغّل `pnpm testbox:sanity` داخل الصندوق أولًا.
|
||||
شغّل Testbox من جذر المستودع وفضّل صندوقًا جديدًا مُسخّنًا لإثبات واسع. قبل صرف بوابة بطيئة على صندوق أُعيد استخدامه أو انتهت صلاحيته أو أبلغ للتو عن مزامنة كبيرة على نحو غير متوقع، شغّل `pnpm testbox:sanity` داخل الصندوق أولًا.
|
||||
|
||||
يفشل فحص السلامة بسرعة عندما تختفي ملفات الجذر المطلوبة مثل `pnpm-lock.yaml` أو عندما يعرض `git status --short` ما لا يقل عن 200 حذف متتبع. يعني ذلك عادة أن حالة المزامنة البعيدة ليست نسخة موثوقة من PR؛ أوقف ذلك الصندوق وجهّز صندوقًا جديدًا بدلًا من تصحيح فشل اختبار المنتج. بالنسبة إلى PRs ذات الحذف الكبير المتعمد، عيّن `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1` لتشغيل السلامة ذلك.
|
||||
يفشل فحص السلامة بسرعة عندما تختفي ملفات الجذر المطلوبة مثل `pnpm-lock.yaml` أو عندما يعرض `git status --short` ما لا يقل عن 200 حذف متتبّع. يعني ذلك عادة أن حالة المزامنة البعيدة ليست نسخة موثوقة من طلب PR؛ أوقف ذلك الصندوق وسخّن صندوقًا جديدًا بدلًا من تصحيح فشل اختبار المنتج. لطلبات PR ذات الحذف الكبير المتعمّد، عيّن `OPENCLAW_TESTBOX_ALLOW_MASS_DELETIONS=1` لذلك تشغيل السلامة.
|
||||
|
||||
ينهي `pnpm testbox:run` أيضًا استدعاء Blacksmith CLI محليًا يبقى في مرحلة المزامنة لأكثر من خمس دقائق دون مخرجات بعد المزامنة. عيّن `OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0` لتعطيل ذلك الحارس، أو استخدم قيمة أكبر بالمللي ثانية للفروقات المحلية الكبيرة على نحو غير معتاد.
|
||||
ينهي `pnpm testbox:run` أيضًا استدعاء Blacksmith CLI محليًا يبقى في مرحلة المزامنة لأكثر من خمس دقائق دون إخراج بعد المزامنة. عيّن `OPENCLAW_TESTBOX_SYNC_TIMEOUT_MS=0` لتعطيل ذلك الحارس، أو استخدم قيمة أكبر بالميلي ثانية للفروق المحلية الكبيرة على نحو غير معتاد.
|
||||
|
||||
## ذات صلة
|
||||
## ذو صلة
|
||||
|
||||
- [نظرة عامة على التثبيت](/ar/install)
|
||||
- [قنوات التطوير](/ar/install/development-channels)
|
||||
|
||||
@ -1,48 +1,49 @@
|
||||
---
|
||||
read_when:
|
||||
- تحتاج إلى شرح تفصيلي دقيق لحلقة الوكيل أو أحداث دورة الحياة
|
||||
- أنت تغيّر وضع الجلسات في قائمة الانتظار، أو عمليات كتابة السجل النصي، أو سلوك قفل الكتابة للجلسة
|
||||
- أنت تغيّر آلية اصطفاف الجلسات، أو عمليات كتابة السجل النصي، أو سلوك قفل كتابة الجلسة
|
||||
summary: دورة حياة حلقة الوكيل، والتدفقات، ودلالات الانتظار
|
||||
title: حلقة الوكيل
|
||||
x-i18n:
|
||||
generated_at: "2026-04-30T07:51:14Z"
|
||||
generated_at: "2026-04-30T18:38:49Z"
|
||||
model: gpt-5.5
|
||||
provider: openai
|
||||
source_hash: 902d543bd71dd517a810d825cbe92e244fe89230f47eeada72477c657a2bec32
|
||||
source_hash: 5466893253e1f82482284ff82db56f4c3fca018bf12e4114fad76d37cad954df
|
||||
source_path: concepts/agent-loop.md
|
||||
workflow: 16
|
||||
---
|
||||
|
||||
حلقة الوكيل هي التشغيل "الحقيقي" الكامل للوكيل: الاستقبال ← تجميع السياق ← استدلال النموذج ←
|
||||
تنفيذ الأدوات ← الردود المتدفقة ← الحفظ. وهي المسار الموثوق الذي يحوّل رسالة
|
||||
حلقة الوكيلية هي التشغيل الكامل "الحقيقي" للوكيل: الإدخال → تجميع السياق → استدلال النموذج →
|
||||
تنفيذ الأدوات → بث الردود → الاستمرارية. وهي المسار الموثوق الذي يحوّل الرسالة
|
||||
إلى إجراءات ورد نهائي، مع الحفاظ على اتساق حالة الجلسة.
|
||||
|
||||
في OpenClaw، تكون الحلقة تشغيلاً واحداً ومتسلسلاً لكل جلسة، وتُصدر أحداث دورة الحياة والتدفق
|
||||
أثناء تفكير النموذج واستدعائه للأدوات وبثه للمخرجات. يشرح هذا المستند كيف تُوصَل تلك الحلقة الأصيلة
|
||||
في OpenClaw، الحلقة هي تشغيل واحد ومتسلسل لكل جلسة، يصدر أحداث دورة الحياة والبث
|
||||
بينما يفكر النموذج، ويستدعي الأدوات، ويبث المخرجات. يشرح هذا المستند كيف تُوصَل تلك الحلقة الأصيلة
|
||||
من البداية إلى النهاية.
|
||||
|
||||
## نقاط الدخول
|
||||
|
||||
- Gateway RPC: `agent` و`agent.wait`.
|
||||
- Gateway RPC: `agent` و `agent.wait`.
|
||||
- CLI: أمر `agent`.
|
||||
|
||||
## كيف يعمل (على مستوى عال)
|
||||
## كيف يعمل ذلك (نظرة عامة)
|
||||
|
||||
1. يتحقق `agent` RPC من المعاملات، ويحل الجلسة (sessionKey/sessionId)، ويحفظ بيانات تعريف الجلسة، ثم يعيد `{ runId, acceptedAt }` فوراً.
|
||||
2. يشغّل `agentCommand` الوكيل:
|
||||
- يحل النموذج + الإعدادات الافتراضية للتفكير/الإسهاب/التتبع
|
||||
1. يتحقق `agent` RPC من المعاملات، ويحل الجلسة (sessionKey/sessionId)، ويحفظ بيانات تعريف الجلسة، ويعيد `{ runId, acceptedAt }` فورًا.
|
||||
2. يشغل `agentCommand` الوكيل:
|
||||
- يحل النموذج + افتراضيات التفكير/الإسهاب/التتبع
|
||||
- يحمّل لقطة Skills
|
||||
- يستدعي `runEmbeddedPiAgent` (وقت تشغيل pi-agent-core)
|
||||
- يصدر **نهاية/خطأ دورة الحياة** إذا لم تُصدر الحلقة المضمنة واحداً
|
||||
3. `runEmbeddedPiAgent`:
|
||||
- يصدر **نهاية/خطأ دورة الحياة** إذا لم تصدر الحلقة المضمنة واحدًا
|
||||
3. يقوم `runEmbeddedPiAgent` بما يلي:
|
||||
- يسلسل عمليات التشغيل عبر طوابير لكل جلسة + طوابير عامة
|
||||
- يحل النموذج + ملف تعريف المصادقة ويبني جلسة pi
|
||||
- يشترك في أحداث pi ويبث فروقات المساعد/الأداة
|
||||
- يفرض المهلة -> يجهض التشغيل عند تجاوزها
|
||||
- يشترك في أحداث pi ويبث دلتا المساعد/الأداة
|
||||
- يفرض المهلة -> يلغي التشغيل إذا تم تجاوزها
|
||||
- بالنسبة إلى أدوار خادم تطبيق Codex، يلغي الدور المقبول الذي يتوقف عن إنتاج تقدم خادم التطبيق قبل حدث نهائي
|
||||
- يعيد الحمولات + بيانات تعريف الاستخدام
|
||||
4. يربط `subscribeEmbeddedPiSession` أحداث pi-agent-core بتدفق `agent` في OpenClaw:
|
||||
- أحداث الأدوات => `stream: "tool"`
|
||||
- فروقات المساعد => `stream: "assistant"`
|
||||
4. يربط `subscribeEmbeddedPiSession` أحداث pi-agent-core ببث `agent` في OpenClaw:
|
||||
- أحداث الأداة => `stream: "tool"`
|
||||
- دلتا المساعد => `stream: "assistant"`
|
||||
- أحداث دورة الحياة => `stream: "lifecycle"` (`phase: "start" | "end" | "error"`)
|
||||
5. يستخدم `agent.wait` الدالة `waitForAgentRun`:
|
||||
- ينتظر **نهاية/خطأ دورة الحياة** لـ `runId`
|
||||
@ -50,133 +51,133 @@ x-i18n:
|
||||
|
||||
## الطوابير + التزامن
|
||||
|
||||
- تُسلسل عمليات التشغيل لكل مفتاح جلسة (مسار الجلسة) واختيارياً عبر مسار عام.
|
||||
- تُسلسل عمليات التشغيل لكل مفتاح جلسة (مسار الجلسة)، واختياريًا عبر مسار عام.
|
||||
- يمنع هذا تعارضات الأدوات/الجلسات ويحافظ على اتساق سجل الجلسة.
|
||||
- يمكن لقنوات المراسلة اختيار أوضاع الطابور (collect/steer/followup) التي تغذي نظام المسارات هذا.
|
||||
راجع [طابور الأوامر](/ar/concepts/queue).
|
||||
- كما تُحمى كتابات النصوص أيضاً بقفل كتابة جلسة على ملف الجلسة. القفل
|
||||
واع بالعملية وقائم على الملفات، لذا يلتقط الكتّاب الذين يتجاوزون الطابور داخل العملية أو يأتون من
|
||||
- تُحمى كتابات النص المنسوخ أيضًا بقفل كتابة جلسة على ملف الجلسة. القفل
|
||||
مدرك للعمليات وقائم على الملفات، لذلك يلتقط الكتّاب الذين يتجاوزون الطابور داخل العملية أو يأتون من
|
||||
عملية أخرى.
|
||||
- أقفال كتابة الجلسة غير قابلة لإعادة الدخول افتراضياً. إذا كان مساعد ما يضمّن عمداً الحصول على
|
||||
القفل نفسه مع الحفاظ على كاتب منطقي واحد، فيجب أن يشترك صراحة باستخدام
|
||||
- أقفال كتابة الجلسة غير قابلة لإعادة الدخول افتراضيًا. إذا كان مساعد ما يتداخل عمدًا في الحصول على
|
||||
القفل نفسه مع الحفاظ على كاتب منطقي واحد، فيجب أن يفعّل ذلك صراحةً باستخدام
|
||||
`allowReentrant: true`.
|
||||
|
||||
## إعداد الجلسة + مساحة العمل
|
||||
|
||||
- تُحل مساحة العمل وتُنشأ؛ وقد تعيد عمليات التشغيل المعزولة توجيهها إلى جذر مساحة عمل معزولة.
|
||||
- تُحمّل Skills (أو يُعاد استخدامها من لقطة) وتُحقن في البيئة والمطالبة.
|
||||
- تُحل ملفات التمهيد/السياق وتُحقن في تقرير مطالبة النظام.
|
||||
- يُكتسب قفل كتابة الجلسة؛ ويُفتح `SessionManager` ويُجهز قبل البث. يجب على أي
|
||||
مسار لاحق لإعادة كتابة النص، أو Compaction، أو الاقتطاع أخذ القفل نفسه قبل فتح ملف النص أو
|
||||
تعديله.
|
||||
- تُحمّل Skills (أو يعاد استخدامها من لقطة) وتُحقن في البيئة والموجه.
|
||||
- تُحل ملفات bootstrap/السياق وتُحقن في تقرير موجه النظام.
|
||||
- يُكتسب قفل كتابة جلسة؛ ويُفتح `SessionManager` ويُجهز قبل البث. يجب على أي
|
||||
مسار لاحق لإعادة كتابة النص المنسوخ أو Compaction أو الاقتطاع أن يأخذ القفل نفسه قبل فتح
|
||||
ملف النص المنسوخ أو تعديله.
|
||||
|
||||
## تجميع المطالبة + مطالبة النظام
|
||||
## تجميع الموجه + موجه النظام
|
||||
|
||||
- تُبنى مطالبة النظام من مطالبة OpenClaw الأساسية، ومطالبة Skills، وسياق التمهيد، والتجاوزات الخاصة بكل تشغيل.
|
||||
- تُفرض حدود خاصة بالنموذج ورموز احتياط Compaction.
|
||||
- راجع [مطالبة النظام](/ar/concepts/system-prompt) لمعرفة ما يراه النموذج.
|
||||
- يُبنى موجه النظام من الموجه الأساسي في OpenClaw، وموجه Skills، وسياق bootstrap، والتجاوزات الخاصة بكل تشغيل.
|
||||
- تُفرض حدود النموذج المحددة ورموز احتياطي Compaction.
|
||||
- راجع [موجه النظام](/ar/concepts/system-prompt) لمعرفة ما يراه النموذج.
|
||||
|
||||
## نقاط الربط (حيث يمكنك الاعتراض)
|
||||
## نقاط الخطاف (حيث يمكنك الاعتراض)
|
||||
|
||||
لدى OpenClaw نظاما ربط:
|
||||
لدى OpenClaw نظاما خطافات:
|
||||
|
||||
- **الربط الداخلي** (ربط Gateway): سكربتات مدفوعة بالأحداث للأوامر وأحداث دورة الحياة.
|
||||
- **ربط Plugin**: نقاط توسعة داخل دورة حياة الوكيل/الأداة وخط أنابيب Gateway.
|
||||
- **الخطافات الداخلية** (خطافات Gateway): سكربتات مدفوعة بالأحداث للأوامر وأحداث دورة الحياة.
|
||||
- **خطافات Plugin**: نقاط توسعة داخل دورة حياة الوكيل/الأداة وخط أنابيب Gateway.
|
||||
|
||||
### الربط الداخلي (ربط Gateway)
|
||||
### الخطافات الداخلية (خطافات Gateway)
|
||||
|
||||
- **`agent:bootstrap`**: يعمل أثناء بناء ملفات التمهيد قبل إنهاء مطالبة النظام.
|
||||
استخدمه لإضافة/إزالة ملفات سياق التمهيد.
|
||||
- **ربط الأوامر**: `/new` و`/reset` و`/stop` وأحداث أوامر أخرى (راجع مستند الربط).
|
||||
- **`agent:bootstrap`**: يعمل أثناء بناء ملفات bootstrap قبل إنهاء موجه النظام.
|
||||
استخدم هذا لإضافة/إزالة ملفات سياق bootstrap.
|
||||
- **خطافات الأوامر**: `/new`، و`/reset`، و`/stop`، وأحداث أوامر أخرى (راجع مستند الخطافات).
|
||||
|
||||
راجع [الربط](/ar/automation/hooks) للإعداد والأمثلة.
|
||||
راجع [الخطافات](/ar/automation/hooks) للإعداد والأمثلة.
|
||||
|
||||
### ربط Plugin (دورة حياة الوكيل + Gateway)
|
||||
### خطافات Plugin (دورة حياة الوكيل + Gateway)
|
||||
|
||||
تعمل هذه داخل حلقة الوكيل أو خط أنابيب Gateway:
|
||||
|
||||
- **`before_model_resolve`**: يعمل قبل الجلسة (بدون `messages`) لتجاوز المزوّد/النموذج بشكل حتمي قبل حل النموذج.
|
||||
- **`before_prompt_build`**: يعمل بعد تحميل الجلسة (مع `messages`) لحقن `prependContext` أو `systemPrompt` أو `prependSystemContext` أو `appendSystemContext` قبل إرسال المطالبة. استخدم `prependContext` للنص الديناميكي لكل دور، وحقول سياق النظام للإرشادات الثابتة التي يجب أن تكون في مساحة مطالبة النظام.
|
||||
- **`before_agent_start`**: ربط توافق قديم قد يعمل في أي من المرحلتين؛ فضّل الربط الصريح أعلاه.
|
||||
- **`before_agent_reply`**: يعمل بعد الإجراءات المضمنة وقبل استدعاء LLM، مما يتيح لـ Plugin امتلاك الدور وإرجاع رد اصطناعي أو إسكات الدور بالكامل.
|
||||
- **`agent_end`**: افحص قائمة الرسائل النهائية وبيانات تعريف التشغيل بعد الاكتمال.
|
||||
- **`before_compaction` / `after_compaction`**: راقب دورات Compaction أو أضف تعليقات توضيحية إليها.
|
||||
- **`before_tool_call` / `after_tool_call`**: اعترض معاملات/نتائج الأدوات.
|
||||
- **`before_install`**: افحص نتائج الفحص المدمجة واختيارياً احظر تثبيت Skills أو Plugin.
|
||||
- **`tool_result_persist`**: حوّل نتائج الأدوات بشكل متزامن قبل كتابتها في نص جلسة مملوك لـ OpenClaw.
|
||||
- **`message_received` / `message_sending` / `message_sent`**: ربط الرسائل الواردة + الصادرة.
|
||||
- **`before_model_resolve`**: يعمل قبل الجلسة (بلا `messages`) لتجاوز المزود/النموذج بشكل حتمي قبل حل النموذج.
|
||||
- **`before_prompt_build`**: يعمل بعد تحميل الجلسة (مع `messages`) لحقن `prependContext` أو `systemPrompt` أو `prependSystemContext` أو `appendSystemContext` قبل إرسال الموجه. استخدم `prependContext` للنص الديناميكي لكل دور، وحقول سياق النظام للإرشادات المستقرة التي يجب أن تقع في مساحة موجه النظام.
|
||||
- **`before_agent_start`**: خطاف توافق قديم قد يعمل في أي من المرحلتين؛ فضّل الخطافات الصريحة أعلاه.
|
||||
- **`before_agent_reply`**: يعمل بعد الإجراءات المضمنة وقبل استدعاء LLM، مما يتيح لـ Plugin المطالبة بالدور وإرجاع رد اصطناعي أو إسكات الدور بالكامل.
|
||||
- **`agent_end`**: يفحص قائمة الرسائل النهائية وبيانات تعريف التشغيل بعد الاكتمال.
|
||||
- **`before_compaction` / `after_compaction`**: يراقب دورات Compaction أو يعلق عليها.
|
||||
- **`before_tool_call` / `after_tool_call`**: يعترض معاملات/نتائج الأدوات.
|
||||
- **`before_install`**: يفحص نتائج الفحص المدمجة ويمكنه اختياريًا حظر تثبيت Skills أو Plugins.
|
||||
- **`tool_result_persist`**: يحوّل نتائج الأدوات بشكل متزامن قبل كتابتها إلى نص جلسة منسوخ مملوك لـ OpenClaw.
|
||||
- **`message_received` / `message_sending` / `message_sent`**: خطافات الرسائل الواردة + الصادرة.
|
||||
- **`session_start` / `session_end`**: حدود دورة حياة الجلسة.
|
||||
- **`gateway_start` / `gateway_stop`**: أحداث دورة حياة Gateway.
|
||||
|
||||
قواعد قرار الربط لحراس الصادر/الأداة:
|
||||
قواعد قرارات الخطافات لحراس الإرسال/الأدوات:
|
||||
|
||||
- `before_tool_call`: تكون `{ block: true }` نهائية وتوقف المعالجات ذات الأولوية الأدنى.
|
||||
- `before_tool_call`: تكون `{ block: false }` بلا تأثير ولا تزيل حظراً سابقاً.
|
||||
- `before_install`: تكون `{ block: true }` نهائية وتوقف المعالجات ذات الأولوية الأدنى.
|
||||
- `before_install`: تكون `{ block: false }` بلا تأثير ولا تزيل حظراً سابقاً.
|
||||
- `message_sending`: تكون `{ cancel: true }` نهائية وتوقف المعالجات ذات الأولوية الأدنى.
|
||||
- `message_sending`: تكون `{ cancel: false }` بلا تأثير ولا تزيل إلغاء سابقاً.
|
||||
- `before_tool_call`: يكون `{ block: true }` نهائيًا ويوقف المعالجات ذات الأولوية الأدنى.
|
||||
- `before_tool_call`: يكون `{ block: false }` بلا أثر ولا يمحو حظرًا سابقًا.
|
||||
- `before_install`: يكون `{ block: true }` نهائيًا ويوقف المعالجات ذات الأولوية الأدنى.
|
||||
- `before_install`: يكون `{ block: false }` بلا أثر ولا يمحو حظرًا سابقًا.
|
||||
- `message_sending`: يكون `{ cancel: true }` نهائيًا ويوقف المعالجات ذات الأولوية الأدنى.
|
||||
- `message_sending`: يكون `{ cancel: false }` بلا أثر ولا يمحو إلغاءً سابقًا.
|
||||
|
||||
راجع [ربط Plugin](/ar/plugins/hooks) لتفاصيل واجهة API للربط والتسجيل.
|
||||
راجع [خطافات Plugin](/ar/plugins/hooks) لتفاصيل واجهة API للخطاف والتسجيل.
|
||||
|
||||
قد تكيّف الحاضنات هذا الربط بطرق مختلفة. تحافظ حاضنة خادم تطبيق Codex على
|
||||
ربط Plugin في OpenClaw كعقد توافق للأسطح الموثقة المعكوسة،
|
||||
بينما تظل ربطات Codex الأصلية آلية Codex منفصلة ذات مستوى أدنى.
|
||||
قد تكيف الحاضنات هذه الخطافات بطرق مختلفة. تحافظ حاضنة خادم تطبيق Codex على
|
||||
خطافات Plugin في OpenClaw باعتبارها عقد التوافق للأسطح المرآتية الموثقة،
|
||||
بينما تظل خطافات Codex الأصلية آلية Codex منخفضة المستوى منفصلة.
|
||||
|
||||
## البث + الردود الجزئية
|
||||
|
||||
- تُبث فروقات المساعد من pi-agent-core وتُصدر كأحداث `assistant`.
|
||||
- تُبث دلتا المساعد من pi-agent-core وتُصدر كأحداث `assistant`.
|
||||
- يمكن لبث الكتل إصدار ردود جزئية إما عند `text_end` أو `message_end`.
|
||||
- يمكن إصدار بث الاستدلال كتدفق منفصل أو كردود كتل.
|
||||
- راجع [البث](/ar/concepts/streaming) لسلوك التقسيم إلى أجزاء وردود الكتل.
|
||||
- يمكن إصدار بث الاستدلال كبث منفصل أو كردود كتل.
|
||||
- راجع [البث](/ar/concepts/streaming) لمعرفة سلوك التجزئة وردود الكتل.
|
||||
|
||||
## تنفيذ الأدوات + أدوات المراسلة
|
||||
|
||||
- تُصدر أحداث بدء/تحديث/انتهاء الأداة على تدفق `tool`.
|
||||
- تُنظف نتائج الأدوات من حيث الحجم وحمولات الصور قبل التسجيل/الإصدار.
|
||||
- تُتبع عمليات إرسال أدوات المراسلة لكبح تأكيدات المساعد المكررة.
|
||||
- تُصدر أحداث بدء/تحديث/نهاية الأداة على بث `tool`.
|
||||
- تُنقح نتائج الأدوات من حيث الحجم وحمولات الصور قبل التسجيل/الإصدار.
|
||||
- تُتبع عمليات إرسال أدوات المراسلة لمنع تأكيدات المساعد المكررة.
|
||||
|
||||
## تشكيل الرد + الكبح
|
||||
## تشكيل الرد + الكبت
|
||||
|
||||
- تُجمع الحمولات النهائية من:
|
||||
- تُجمّع الحمولات النهائية من:
|
||||
- نص المساعد (والاستدلال الاختياري)
|
||||
- ملخصات الأدوات المضمنة (عند الإسهاب + السماح)
|
||||
- نص خطأ المساعد عند حدوث خطأ في النموذج
|
||||
- يُصفّى الرمز الصامت الدقيق `NO_REPLY` / `no_reply` من الحمولات
|
||||
- نص خطأ المساعد عندما يخطئ النموذج
|
||||
- تُرشح العلامة الصامتة الدقيقة `NO_REPLY` / `no_reply` من الحمولات
|
||||
الصادرة.
|
||||
- تُزال تكرارات أدوات المراسلة من قائمة الحمولات النهائية.
|
||||
- إذا لم تبق أي حمولات قابلة للعرض وحدث خطأ في أداة، يُصدر رد خطأ أداة احتياطي
|
||||
(ما لم تكن أداة مراسلة قد أرسلت بالفعل رداً مرئياً للمستخدم).
|
||||
- إذا لم تبقَ أي حمولات قابلة للعرض وحدث خطأ في أداة، يُصدر رد احتياطي لخطأ الأداة
|
||||
(ما لم تكن أداة مراسلة قد أرسلت بالفعل ردًا مرئيًا للمستخدم).
|
||||
|
||||
## Compaction + إعادة المحاولة
|
||||
## Compaction + إعادة المحاولات
|
||||
|
||||
- يصدر Compaction التلقائي أحداث تدفق `compaction` ويمكنه تشغيل إعادة محاولة.
|
||||
- عند إعادة المحاولة، تُعاد تعيين المخازن المؤقتة داخل الذاكرة وملخصات الأدوات لتجنب تكرار المخرجات.
|
||||
- يصدر Compaction التلقائي أحداث بث `compaction` ويمكنه تشغيل إعادة محاولة.
|
||||
- عند إعادة المحاولة، تُعاد تهيئة المخازن المؤقتة داخل الذاكرة وملخصات الأدوات لتجنب تكرار المخرجات.
|
||||
- راجع [Compaction](/ar/concepts/compaction) لمعرفة خط أنابيب Compaction.
|
||||
|
||||
## تدفقات الأحداث (اليوم)
|
||||
|
||||
- `lifecycle`: يصدره `subscribeEmbeddedPiSession` (وكاحتياطي بواسطة `agentCommand`)
|
||||
- `assistant`: فروقات متدفقة من pi-agent-core
|
||||
- `tool`: أحداث أدوات متدفقة من pi-agent-core
|
||||
- `assistant`: دلتا مبثوثة من pi-agent-core
|
||||
- `tool`: أحداث أدوات مبثوثة من pi-agent-core
|
||||
|
||||
## معالجة قناة الدردشة
|
||||
## معالجة قنوات الدردشة
|
||||
|
||||
- تُخزن فروقات المساعد مؤقتاً في رسائل دردشة `delta`.
|
||||
- تُصدر دردشة `final` عند **نهاية/خطأ دورة الحياة**.
|
||||
- تُخزن دلتا المساعد في رسائل `delta` للدردشة.
|
||||
- تُصدر `final` للدردشة عند **نهاية/خطأ دورة الحياة**.
|
||||
|
||||
## المهلات
|
||||
## المهل
|
||||
|
||||
- الافتراضي لـ `agent.wait`: 30 ثانية (الانتظار فقط). يتجاوزه معامل `timeoutMs`.
|
||||
- وقت تشغيل الوكيل: الافتراضي لـ `agents.defaults.timeoutSeconds` هو 172800 ثانية (48 ساعة)؛ ويُفرض في مؤقت إجهاض `runEmbeddedPiAgent`.
|
||||
- وقت تشغيل Cron: يملك Cron قيمة `timeoutSeconds` المعزولة لدور الوكيل. يبدأ المجدول ذلك المؤقت عند بدء التنفيذ، ويجهض التشغيل الأساسي عند الموعد النهائي المضبوط، ثم يجري تنظيفاً محدوداً قبل تسجيل المهلة بحيث لا تستطيع جلسة فرعية قديمة إبقاء المسار عالقاً.
|
||||
- استرداد الجلسات العالقة: مع تمكين التشخيصات، يكتشف `diagnostics.stuckSessionWarnMs` الجلسات الطويلة ذات حالة `processing`. تظل عمليات التشغيل المضمنة النشطة، وعمليات الرد النشطة، ومهام مسار الجلسة النشطة تحذيرية فقط افتراضياً؛ وإذا أظهرت التشخيصات عدم وجود عمل نشط للجلسة، يحرر المراقب مسار الجلسة المتأثر لكي تُصرّف أعمال بدء التشغيل الموجودة في الطابور.
|
||||
- مهلة خمول النموذج: يجهض OpenClaw طلب النموذج عندما لا تصل أجزاء استجابة قبل نافذة الخمول. يمدد `models.providers.<id>.timeoutSeconds` مراقب الخمول هذا للمزوّدين المحليين/المستضافين ذاتياً البطيئين؛ وإلا يستخدم OpenClaw `agents.defaults.timeoutSeconds` عند ضبطه، مع حد أقصى افتراضي قدره 120 ثانية. عمليات التشغيل المشغلة بواسطة Cron التي لا تحتوي على مهلة نموذج أو وكيل صريحة تعطل مراقب الخمول وتعتمد على مهلة Cron الخارجية.
|
||||
- مهلة طلب HTTP للمزوّد: ينطبق `models.providers.<id>.timeoutSeconds` على عمليات جلب HTTP للنموذج الخاصة بذلك المزوّد، بما في ذلك الاتصال، والرؤوس، والجسم، ومهلة طلب SDK، ومعالجة إجهاض الجلب المحروس الإجمالية، ومراقب خمول تدفق النموذج. استخدم هذا للمزوّدين المحليين/المستضافين ذاتياً البطيئين مثل Ollama قبل رفع مهلة وقت تشغيل الوكيل بالكامل.
|
||||
- افتراضي `agent.wait`: 30 ثانية (الانتظار فقط). يتجاوز معامل `timeoutMs` ذلك.
|
||||
- وقت تشغيل الوكيل: افتراضي `agents.defaults.timeoutSeconds` هو 172800 ثانية (48 ساعة)؛ ويُفرض في مؤقت إلغاء `runEmbeddedPiAgent`.
|
||||
- وقت تشغيل Cron: يملك Cron قيمة `timeoutSeconds` لدور الوكيل المعزول. يبدأ المجدول ذلك المؤقت عند بدء التنفيذ، ويلغي التشغيل الأساسي عند الموعد النهائي المهيأ، ثم يشغل تنظيفًا محدودًا قبل تسجيل انتهاء المهلة حتى لا تتمكن جلسة فرعية قديمة من إبقاء المسار عالقًا.
|
||||
- استرداد الجلسة العالقة: عند تمكين التشخيصات، يكتشف `diagnostics.stuckSessionWarnMs` جلسات `processing` الطويلة. تظل عمليات التشغيل المضمنة النشطة، وعمليات الرد النشطة، ومهام مسار الجلسة النشطة تحذيرية فقط افتراضيًا؛ إذا أظهرت التشخيصات عدم وجود عمل نشط للجلسة، يحرر المراقب مسار الجلسة المتأثر حتى يمكن تصريف عمل بدء التشغيل في الطابور.
|
||||
- مهلة خمول النموذج: يلغي OpenClaw طلب النموذج عندما لا تصل أي أجزاء استجابة قبل نافذة الخمول. يمدد `models.providers.<id>.timeoutSeconds` مراقب الخمول هذا للمزودين المحليين/ذاتيي الاستضافة البطيئين؛ وإلا يستخدم OpenClaw قيمة `agents.defaults.timeoutSeconds` عند تهيئتها، مع حد أقصى افتراضي 120 ثانية. تعمل عمليات التشغيل المشغلة بواسطة Cron بلا مهلة صريحة للنموذج أو الوكيل على تعطيل مراقب الخمول وتعتمد على مهلة Cron الخارجية.
|
||||
- مهلة طلب HTTP للمزود: يطبق `models.providers.<id>.timeoutSeconds` على جلب HTTP للنموذج الخاص بذلك المزود، بما في ذلك الاتصال، والرؤوس، والجسم، ومهلة طلب SDK، ومعالجة الإلغاء الكلي لـ guarded-fetch، ومراقب خمول بث النموذج. استخدم هذا للمزودين المحليين/ذاتيي الاستضافة البطيئين مثل Ollama قبل رفع مهلة وقت تشغيل الوكيل بالكامل.
|
||||
|
||||
## أين يمكن أن تنتهي الأمور مبكراً
|
||||
## أين يمكن أن تنتهي الأشياء مبكرًا
|
||||
|
||||
- مهلة الوكيل (إجهاض)
|
||||
- مهلة الوكيل (إلغاء)
|
||||
- AbortSignal (إلغاء)
|
||||
- انقطاع Gateway أو مهلة RPC
|
||||
- مهلة `agent.wait` (انتظار فقط، لا توقف الوكيل)
|
||||
@ -184,7 +185,7 @@ x-i18n:
|
||||
## ذو صلة
|
||||
|
||||
- [الأدوات](/ar/tools) — أدوات الوكيل المتاحة
|
||||
- [الربط](/ar/automation/hooks) — سكربتات مدفوعة بالأحداث تُشغّلها أحداث دورة حياة الوكيل
|
||||
- [الخطافات](/ar/automation/hooks) — سكربتات مدفوعة بالأحداث تُشغلها أحداث دورة حياة الوكيل
|
||||
- [Compaction](/ar/concepts/compaction) — كيف تُلخص المحادثات الطويلة
|
||||
- [موافقات Exec](/ar/tools/exec-approvals) — بوابات الموافقة لأوامر الصدفة
|
||||
- [التفكير](/ar/tools/thinking) — تكوين مستوى التفكير/الاستدلال
|
||||
- [موافقات Exec](/ar/tools/exec-approvals) — بوابات الموافقة لأوامر shell
|
||||
- [التفكير](/ar/tools/thinking) — تهيئة مستوى التفكير/الاستدلال
|
||||
|
||||
@ -2,63 +2,63 @@
|
||||
read_when:
|
||||
- تغيير تنفيذ الرد التلقائي أو التزامنه
|
||||
- شرح أوضاع /queue أو سلوك توجيه الرسائل
|
||||
summary: أوضاع قائمة انتظار الرد التلقائي، والقيم الافتراضية، والتجاوزات لكل جلسة
|
||||
summary: أوضاع قائمة انتظار الرد التلقائي، والقيم الافتراضية، والتجاوزات على مستوى كل جلسة
|
||||
title: قائمة انتظار الأوامر
|
||||
x-i18n:
|
||||
generated_at: "2026-04-30T07:54:51Z"
|
||||
generated_at: "2026-04-30T18:38:43Z"
|
||||
model: gpt-5.5
|
||||
provider: openai
|
||||
source_hash: 2ac0c0ded9558b080714fa4b8be0d552f985911bf19b427020f9654ae4955b2d
|
||||
source_hash: fbf1bb1ffd4ce06fa138f63e31651b8821226d9c95dd6b93d68326a5fb91fdd0
|
||||
source_path: concepts/queue.md
|
||||
workflow: 16
|
||||
---
|
||||
|
||||
نُسلسل عمليات تشغيل الرد التلقائي الواردة (كل القنوات) عبر قائمة انتظار صغيرة داخل العملية لمنع تصادم عمليات تشغيل الوكلاء المتعددة، مع السماح بالتوازي الآمن عبر الجلسات.
|
||||
نُسلسل تشغيلات الرد التلقائي الواردة (كل القنوات) عبر طابور صغير داخل العملية لمنع تصادم تشغيلات متعددة للوكيل، مع السماح بالتوازي الآمن عبر الجلسات.
|
||||
|
||||
## لماذا
|
||||
|
||||
- يمكن أن تكون عمليات تشغيل الرد التلقائي مكلفة (استدعاءات LLM) وقد تتصادم عند وصول عدة رسائل واردة في أوقات متقاربة.
|
||||
- يمنع التسلسل التنافس على الموارد المشتركة (ملفات الجلسة، السجلات، stdin الخاص بـ CLI) ويقلل احتمال بلوغ حدود المعدل لدى الجهات الأعلى.
|
||||
- قد تكون تشغيلات الرد التلقائي مكلفة (استدعاءات نماذج اللغة الكبيرة) وقد تتصادم عند وصول رسائل واردة متعددة في أوقات متقاربة.
|
||||
- يتجنب التسلسل التنافس على الموارد المشتركة (ملفات الجلسات، السجلات، إدخال CLI القياسي) ويقلل احتمال بلوغ حدود المعدلات لدى المصدر العلوي.
|
||||
|
||||
## كيف يعمل
|
||||
|
||||
- تُفرغ قائمة انتظار FIFO واعية بالمسارات كل مسار مع حد تزامن قابل للضبط (الافتراضي 1 للمسارات غير المضبوطة؛ الافتراضي لـ main هو 4، ولـ subagent هو 8).
|
||||
- يضع `runEmbeddedPiAgent` العناصر في قائمة الانتظار حسب **مفتاح الجلسة** (المسار `session:<key>`) لضمان وجود عملية تشغيل نشطة واحدة فقط لكل جلسة.
|
||||
- ثم تُضاف كل عملية تشغيل جلسة إلى **مسار عام** (`main` افتراضياً) بحيث يكون إجمالي التوازي محدوداً بواسطة `agents.defaults.maxConcurrent`.
|
||||
- عند تفعيل التسجيل المطول، تصدر عمليات التشغيل الموضوعة في قائمة الانتظار إشعاراً قصيراً إذا انتظرت أكثر من حوالي 2 ثانية قبل البدء.
|
||||
- لا تزال مؤشرات الكتابة تُطلق فوراً عند الإضافة إلى قائمة الانتظار (عندما تدعمها القناة)، لذا لا تتغير تجربة المستخدم أثناء انتظار الدور.
|
||||
- يُفرغ طابور أولاً دخولاً أولاً خروجاً مدرك للمسارات كل مسار بحد أقصى قابل للتكوين للتزامن (الافتراضي 1 للمسارات غير المكوّنة؛ ويكون افتراضي `main` هو 4 و`subagent` هو 8).
|
||||
- يضع `runEmbeddedPiAgent` العناصر في الطابور حسب **مفتاح الجلسة** (المسار `session:<key>`) لضمان وجود تشغيل نشط واحد فقط لكل جلسة.
|
||||
- يُوضع كل تشغيل جلسة بعد ذلك في **مسار عام** (`main` افتراضياً) بحيث يكون التوازي الإجمالي محدوداً بواسطة `agents.defaults.maxConcurrent`.
|
||||
- عند تمكين التسجيل المفصل، تصدر التشغيلات الموضوعة في الطابور إشعاراً قصيراً إذا انتظرت أكثر من نحو ثانيتين قبل البدء.
|
||||
- تظل مؤشرات الكتابة تعمل فوراً عند الإضافة إلى الطابور (عندما تدعمها القناة)، لذلك لا تتغير تجربة المستخدم أثناء انتظار الدور.
|
||||
|
||||
## الافتراضيات
|
||||
## الإعدادات الافتراضية
|
||||
|
||||
عند عدم الضبط، تستخدم كل أسطح القنوات الواردة:
|
||||
عند عدم التعيين، تستخدم كل أسطح القنوات الواردة ما يلي:
|
||||
|
||||
- `mode: "steer"`
|
||||
- `debounceMs: 500`
|
||||
- `cap: 20`
|
||||
- `drop: "summarize"`
|
||||
|
||||
`steer` هو الافتراضي لأنه يبقي دورة النموذج النشطة مستجيبة دون
|
||||
بدء عملية تشغيل جلسة ثانية. وهو يفرغ كل رسائل التوجيه التي وصلت
|
||||
قبل حد النموذج التالي. إذا لم تتمكن عملية التشغيل الحالية من قبول التوجيه،
|
||||
يتراجع OpenClaw إلى إدخال متابعة في قائمة الانتظار.
|
||||
`steer` هو الوضع الافتراضي لأنه يحافظ على استجابة دور النموذج النشط دون
|
||||
بدء تشغيل جلسة ثانية. وهو يفرغ كل رسائل التوجيه التي وصلت
|
||||
قبل حدّ النموذج التالي. إذا تعذر على التشغيل الحالي قبول التوجيه،
|
||||
يرجع OpenClaw إلى إدخال طابور متابعة.
|
||||
|
||||
## أوضاع قائمة الانتظار
|
||||
## أوضاع الطابور
|
||||
|
||||
يمكن للرسائل الواردة توجيه عملية التشغيل الحالية، أو انتظار دورة متابعة، أو فعل الأمرين معاً:
|
||||
يمكن للرسائل الواردة توجيه التشغيل الحالي، أو انتظار دور متابعة، أو تنفيذ الأمرين معاً:
|
||||
|
||||
- `steer`: يضع رسائل التوجيه في وقت التشغيل النشط. يسلّم Pi كل رسائل التوجيه المعلقة **بعد أن تنتهي دورة المساعد الحالية من تنفيذ استدعاءات أدواتها**، وقبل استدعاء LLM التالي؛ ويتلقى خادم تطبيق Codex دفعة واحدة من `turn/steer`. إذا لم تكن عملية التشغيل تبث بنشاط أو لم يكن التوجيه متاحاً، يتراجع OpenClaw إلى إدخال متابعة في قائمة الانتظار.
|
||||
- `queue` (قديم): توجيه قديم واحد تلو الآخر. يسلّم Pi رسالة توجيه واحدة موضوعة في قائمة الانتظار عند كل حد نموذج؛ ويتلقى خادم تطبيق Codex طلبات `turn/steer` منفصلة. فضّل `steer` ما لم تكن بحاجة إلى السلوك المتسلسل السابق.
|
||||
- `followup`: يضع كل رسالة في قائمة الانتظار لدورة وكيل لاحقة بعد انتهاء عملية التشغيل الحالية.
|
||||
- `collect`: يدمج الرسائل الموضوعة في قائمة الانتظار في دورة متابعة **واحدة** بعد نافذة الهدوء. إذا كانت الرسائل تستهدف قنوات/سلاسل مختلفة، تُفرغ منفردة للحفاظ على التوجيه.
|
||||
- `steer-backlog` (ويُعرف أيضاً باسم `steer+backlog`): يوجّه الآن **و** يحتفظ بالرسالة نفسها لدورة متابعة.
|
||||
- `interrupt` (قديم): يجهض عملية التشغيل النشطة لتلك الجلسة، ثم يشغّل أحدث رسالة.
|
||||
- `steer`: ضع رسائل التوجيه في طابور وقت التشغيل النشط. يسلّم Pi كل رسائل التوجيه المعلقة **بعد أن ينتهي دور المساعد الحالي من تنفيذ استدعاءات أدواته**، وقبل استدعاء نموذج اللغة الكبيرة التالي؛ ويتلقى Codex app-server دفعة واحدة من `turn/steer`. إذا لم يكن التشغيل يبث بنشاط أو لم يكن التوجيه متاحاً، يرجع OpenClaw إلى إدخال طابور متابعة.
|
||||
- `queue` (قديم): التوجيه القديم واحداً تلو الآخر. يسلّم Pi رسالة توجيه واحدة موضوعة في الطابور عند كل حدّ نموذج؛ ويتلقى Codex app-server طلبات `turn/steer` منفصلة. فضّل `steer` إلا إذا كنت تحتاج إلى السلوك السابق المتسلسل.
|
||||
- `followup`: ضع كل رسالة في الطابور لدور وكيل لاحق بعد انتهاء التشغيل الحالي.
|
||||
- `collect`: ادمج الرسائل الموضوعة في الطابور في دور متابعة **واحد** بعد نافذة الهدوء. إذا كانت الرسائل تستهدف قنوات/سلاسل مختلفة، تُفرغ بشكل منفرد للحفاظ على التوجيه.
|
||||
- `steer-backlog` (ويُعرف أيضاً باسم `steer+backlog`): وجّه الآن **و**احتفظ بالرسالة نفسها لدور متابعة.
|
||||
- `interrupt` (قديم): أوقف التشغيل النشط لتلك الجلسة، ثم شغّل أحدث رسالة.
|
||||
|
||||
يعني Steer-backlog أنك قد تحصل على استجابة متابعة بعد عملية التشغيل الموجّهة، لذا
|
||||
قد تبدو أسطح البث وكأنها تكرر الاستجابات. فضّل `collect`/`steer` إذا كنت تريد
|
||||
يعني Steer-backlog أنك قد تحصل على استجابة متابعة بعد التشغيل الموجّه، لذلك
|
||||
قد تبدو أسطح البث كأنها مكررة. فضّل `collect`/`steer` إذا كنت تريد
|
||||
استجابة واحدة لكل رسالة واردة.
|
||||
|
||||
للاطلاع على توقيت وقت التشغيل وسلوك التبعيات المحدد، راجع
|
||||
[قائمة انتظار التوجيه](/ar/concepts/queue-steering).
|
||||
للتوقيت الخاص بوقت التشغيل وسلوك التبعيات، راجع
|
||||
[طابور التوجيه](/ar/concepts/queue-steering).
|
||||
|
||||
اضبطه عالمياً أو لكل قناة عبر `messages.queue`:
|
||||
|
||||
@ -76,55 +76,55 @@ x-i18n:
|
||||
}
|
||||
```
|
||||
|
||||
## خيارات قائمة الانتظار
|
||||
## خيارات الطابور
|
||||
|
||||
تنطبق الخيارات على `followup` و`collect` و`steer-backlog` (وعلى `steer` أو `queue` القديم عندما يتراجع التوجيه إلى متابعة):
|
||||
تنطبق الخيارات على `followup` و`collect` و`steer-backlog` (وعلى `steer` أو `queue` القديم عندما يرجع التوجيه إلى المتابعة):
|
||||
|
||||
- `debounceMs`: نافذة الهدوء قبل تفريغ المتابعات الموضوعة في قائمة الانتظار. الأرقام المجردة هي بالمللي ثانية؛ وتقبل خيارات `/queue` الوحدات `ms` و`s` و`m` و`h` و`d`.
|
||||
- `cap`: الحد الأقصى للرسائل الموضوعة في قائمة الانتظار لكل جلسة. تُتجاهل القيم الأقل من `1`.
|
||||
- `drop: "summarize"`: الافتراضي. يسقط أقدم الإدخالات الموضوعة في قائمة الانتظار حسب الحاجة، ويحافظ على ملخصات مضغوطة، ويحقنها كمطالبة متابعة اصطناعية.
|
||||
- `drop: "old"`: يسقط أقدم الإدخالات الموضوعة في قائمة الانتظار حسب الحاجة، دون الحفاظ على الملخصات.
|
||||
- `drop: "new"`: يرفض أحدث رسالة عندما تكون قائمة الانتظار ممتلئة بالفعل.
|
||||
- `debounceMs`: نافذة هدوء قبل تفريغ المتابعات الموضوعة في الطابور. الأرقام المجردة بالمللي ثانية؛ وتقبل خيارات `/queue` الوحدات `ms` و`s` و`m` و`h` و`d`.
|
||||
- `cap`: الحد الأقصى للرسائل الموضوعة في الطابور لكل جلسة. تُتجاهل القيم الأقل من `1`.
|
||||
- `drop: "summarize"`: الافتراضي. أسقط أقدم الإدخالات الموضوعة في الطابور حسب الحاجة، واحتفظ بملخصات مضغوطة، واحقنها كموجّه متابعة اصطناعي.
|
||||
- `drop: "old"`: أسقط أقدم الإدخالات الموضوعة في الطابور حسب الحاجة، دون الاحتفاظ بالملخصات.
|
||||
- `drop: "new"`: ارفض أحدث رسالة عندما يكون الطابور ممتلئاً بالفعل.
|
||||
|
||||
الافتراضيات: `debounceMs: 500`، و`cap: 20`، و`drop: summarize`.
|
||||
الإعدادات الافتراضية: `debounceMs: 500`، و`cap: 20`، و`drop: summarize`.
|
||||
|
||||
## الأسبقية
|
||||
|
||||
لاختيار الوضع، يحل OpenClaw وفقاً لما يلي:
|
||||
لاختيار الوضع، يحل OpenClaw بالترتيب التالي:
|
||||
|
||||
1. تجاوز `/queue` مضمّن أو مخزن لكل جلسة.
|
||||
1. تجاوز `/queue` المضمّن أو المخزن لكل جلسة.
|
||||
2. `messages.queue.byChannel.<channel>`.
|
||||
3. `messages.queue.mode`.
|
||||
4. `steer` الافتراضي.
|
||||
|
||||
بالنسبة إلى الخيارات، تتغلب خيارات `/queue` المضمنة أو المخزنة على الضبط. ثم
|
||||
تُطبق مهلة debounce الخاصة بالقناة (`messages.queue.debounceMsByChannel`)، وافتراضيات
|
||||
مهلة debounce الخاصة بالـ plugin، وخيارات `messages.queue` العامة، والافتراضيات
|
||||
المدمجة. يُعد `cap` و`drop` خيارين عامين/خاصين بالجلسة، وليسا مفاتيح ضبط
|
||||
لكل قناة.
|
||||
بالنسبة إلى الخيارات، تتغلب خيارات `/queue` المضمّنة أو المخزنة على التكوين. بعد ذلك
|
||||
تُطبق مهلة الانتظار الخاصة بالقناة (`messages.queue.debounceMsByChannel`)،
|
||||
وافتراضيات مهلة الانتظار في Plugin، وخيارات `messages.queue` العالمية، والافتراضيات المضمنة.
|
||||
`cap` و`drop` خياران عالميان/خاصان بالجلسة، وليسا مفاتيح تكوين لكل قناة.
|
||||
|
||||
## التجاوزات لكل جلسة
|
||||
|
||||
- أرسل `/queue <mode>` كأمر مستقل لتخزين الوضع للجلسة الحالية.
|
||||
- يمكن جمع الخيارات: `/queue collect debounce:0.5s cap:25 drop:summarize`
|
||||
- يمكن دمج الخيارات: `/queue collect debounce:0.5s cap:25 drop:summarize`
|
||||
- يمسح `/queue default` أو `/queue reset` تجاوز الجلسة.
|
||||
|
||||
## النطاق والضمانات
|
||||
|
||||
- ينطبق على عمليات تشغيل وكلاء الرد التلقائي عبر كل القنوات الواردة التي تستخدم مسار رد Gateway (WhatsApp web وTelegram وSlack وDiscord وSignal وiMessage وwebchat، إلخ).
|
||||
- المسار الافتراضي (`main`) على مستوى العملية للوارد + Heartbeat الرئيسية؛ اضبط `agents.defaults.maxConcurrent` للسماح بعدة جلسات بالتوازي.
|
||||
- قد توجد مسارات إضافية (مثل `cron` و`cron-nested` و`nested` و`subagent`) بحيث يمكن للمهام الخلفية العمل بالتوازي دون حظر الردود الواردة. تحتفظ دورات وكيل Cron المعزولة بفتحة `cron` بينما يستخدم تنفيذ الوكيل الداخلي `cron-nested`؛ وكلاهما يستخدم `cron.maxConcurrentRuns`. تحافظ تدفقات `nested` المشتركة غير التابعة لـ Cron على سلوك مسارها الخاص. تُتتبع عمليات التشغيل المنفصلة هذه كـ [مهام خلفية](/ar/automation/tasks).
|
||||
- تضمن مسارات كل جلسة أن عملية تشغيل وكيل واحدة فقط تلمس جلسة معينة في كل مرة.
|
||||
- ينطبق على تشغيلات وكلاء الرد التلقائي عبر كل القنوات الواردة التي تستخدم مسار رد Gateway (WhatsApp web، Telegram، Slack، Discord، Signal، iMessage، webchat، إلخ).
|
||||
- المسار الافتراضي (`main`) على مستوى العملية للوارد + Heartbeats الرئيسية؛ اضبط `agents.defaults.maxConcurrent` للسماح بجلسات متعددة بالتوازي.
|
||||
- قد توجد مسارات إضافية (مثل `cron` و`cron-nested` و`nested` و`subagent`) بحيث يمكن تشغيل المهام الخلفية بالتوازي دون حظر الردود الواردة. تحتفظ أدوار وكيل Cron المعزولة بخانة `cron` بينما يستخدم تنفيذ الوكيل الداخلي `cron-nested`؛ ويستخدم كلاهما `cron.maxConcurrentRuns`. تحافظ تدفقات `nested` المشتركة غير التابعة لـ Cron على سلوك مسارها الخاص. تُتبع هذه التشغيلات المنفصلة كـ[مهام خلفية](/ar/automation/tasks).
|
||||
- تضمن المسارات لكل جلسة أن تشغيل وكيل واحداً فقط يلمس جلسة معينة في كل مرة.
|
||||
- لا توجد تبعيات خارجية أو سلاسل عمال خلفية؛ TypeScript خالص + وعود.
|
||||
|
||||
## استكشاف الأخطاء وإصلاحها
|
||||
|
||||
- إذا بدت الأوامر عالقة، فعّل السجلات المطولة وابحث عن أسطر “queued for …ms” لتأكيد أن قائمة الانتظار تُفرغ.
|
||||
- إذا كنت تحتاج إلى عمق قائمة الانتظار، فعّل السجلات المطولة وراقب أسطر توقيت قائمة الانتظار.
|
||||
- عند تفعيل التشخيصات، تسجل الجلسات التي تبقى في `processing` بعد `diagnostics.stuckSessionWarnMs` تحذيراً بشأن جلسة عالقة. تبقى عمليات التشغيل المضمنة النشطة، وعمليات الرد النشطة، ومهام المسارات النشطة تحذيرية فقط افتراضياً؛ ويمكن لسجلات بدء التشغيل القديمة دون عمل جلسة نشط تحرير مسار الجلسة المتأثرة بحيث يُفرغ العمل الموضوع في قائمة الانتظار.
|
||||
- إذا بدت الأوامر عالقة، فعّل السجلات المفصلة وابحث عن أسطر “queued for …ms” للتأكد من أن الطابور يُفرغ.
|
||||
- إذا كنت تحتاج إلى عمق الطابور، فعّل السجلات المفصلة وراقب أسطر توقيت الطابور.
|
||||
- تشغيلات Codex app-server التي تقبل دوراً ثم تتوقف عن إصدار التقدم تُقاطَع بواسطة محوّل Codex بحيث يمكن تحرير مسار الجلسة النشطة بدلاً من انتظار انتهاء مهلة التشغيل الخارجي.
|
||||
- عند تمكين التشخيصات، تسجل الجلسات التي تبقى في `processing` بعد `diagnostics.stuckSessionWarnMs` تحذير جلسة عالقة. تظل التشغيلات المضمنة النشطة، وعمليات الرد النشطة، ومهام المسارات النشطة تحذيرية فقط افتراضياً؛ ويمكن لمسك دفاتر بدء التشغيل القديم دون عمل جلسة نشط أن يحرر مسار الجلسة المتأثر حتى يُفرغ العمل الموضوع في الطابور.
|
||||
|
||||
## ذات صلة
|
||||
## ذو صلة
|
||||
|
||||
- [إدارة الجلسات](/ar/concepts/session)
|
||||
- [قائمة انتظار التوجيه](/ar/concepts/queue-steering)
|
||||
- [طابور التوجيه](/ar/concepts/queue-steering)
|
||||
- [سياسة إعادة المحاولة](/ar/concepts/retry)
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because one or more lines are too long
Loading…
Reference in New Issue
Block a user