سياسة الإصدارات

Documentation Index

Fetch the complete documentation index at: https://docs.openclaw.ai/llms.txt

Use this file to discover all available pages before exploring further.

• المستقر: إصدارات موسومة تُنشر إلى npm beta افتراضياً، أو إلى npm latest عند طلب ذلك صراحةً
• التجريبي: وسوم ما قبل الإصدار التي تُنشر إلى npm beta
• التطوير: الرأس المتحرك لـ main

​

تسمية الإصدارات

• نسخة الإصدار المستقر: YYYY.M.D
  • وسم Git: vYYYY.M.D
• نسخة إصدار تصحيح مستقر: YYYY.M.D-N
  • وسم Git: vYYYY.M.D-N
• نسخة ما قبل الإصدار التجريبية: YYYY.M.D-beta.N
  • وسم Git: vYYYY.M.D-beta.N
• لا تضف أصفاراً بادئة إلى الشهر أو اليوم
• يعني latest إصدار npm المستقر الحالي الذي تمت ترقيته
• يعني beta هدف التثبيت التجريبي الحالي
• تُنشر الإصدارات المستقرة وإصدارات التصحيح المستقر إلى npm beta افتراضياً؛ يمكن لمشغّلي الإصدار استهداف latest صراحةً، أو ترقية بنية تجريبية مُراجَعة لاحقاً
• كل إصدار OpenClaw مستقر يشحن حزمة npm وتطبيق macOS معاً؛ الإصدارات التجريبية تتحقق عادةً من مسار npm/الحزمة وتنشره أولاً، مع حجز بناء/توقيع/توثيق تطبيق mac لمستقر ما لم يُطلب ذلك صراحةً

​

وتيرة الإصدار

• تتحرك الإصدارات بمنهجية التجريبي أولاً
• لا يأتي المستقر إلا بعد التحقق من أحدث إصدار تجريبي
• عادةً ما يقتطع المشرفون الإصدارات من فرع release/YYYY.M.D مُنشأ من main الحالي، بحيث لا يمنع التحقق من الإصدار وإصلاحاته التطوير الجديد على main
• إذا دُفع وسم تجريبي أو نُشر واحتاج إلى إصلاح، يقتطع المشرفون وسم -beta.N التالي بدلاً من حذف الوسم التجريبي القديم أو إعادة إنشائه
• إجراءات الإصدار التفصيلية، والموافقات، وبيانات الاعتماد، وملاحظات الاسترداد مخصصة للمشرفين فقط

​

قائمة تحقق مشغّل الإصدار

1. ابدأ من main الحالي: اسحب الأحدث، وأكّد أن الالتزام المستهدف قد دُفع، وأكّد أن CI الحالي لـ main أخضر بما يكفي لإنشاء فرع منه.
2. أعد كتابة قسم CHANGELOG.md العلوي من سجل الالتزامات الحقيقي باستخدام /changelog، وأبقِ الإدخالات موجهة للمستخدم، ثم التزم به، وادفعه، وأعد rebase/pull مرة أخرى قبل التفريع.
3. راجع سجلات توافق الإصدار في src/plugins/compat/registry.ts و src/commands/doctor/shared/deprecation-compat.ts. أزل التوافق المنتهي فقط عندما يبقى مسار الترقية مغطى، أو سجّل سبب حمله عمداً.
4. أنشئ release/YYYY.M.D من main الحالي؛ لا تنفذ عمل الإصدار العادي مباشرةً على main.
5. ارفع كل موضع نسخة مطلوب للوسم المقصود، ثم شغّل pnpm release:prep. يحدّث نسخ Plugin، ومخزون Plugin، ومخطط الإعدادات، وبيانات تعريف إعدادات القنوات المضمنة، وخط أساس توثيق الإعدادات، وصادرات Plugin SDK، وخط أساس API الخاص بـ Plugin SDK بالترتيب الصحيح. التزم بأي انحراف مولّد قبل الوسم. ثم شغّل فحص ما قبل الإطلاق المحلي الحتمي: pnpm check:test-types، وpnpm check:architecture، وpnpm build && pnpm ui:build، وpnpm release:check.
6. شغّل OpenClaw NPM Release مع preflight_only=true. قبل وجود وسم، يُسمح باستخدام SHA كامل من 40 محرفاً لفرع الإصدار للتحقق فقط في فحص ما قبل الإطلاق. احفظ preflight_run_id الناجح.
7. ابدأ كل اختبارات ما قبل الإصدار باستخدام Full Release Validation لفرع الإصدار، أو الوسم، أو SHA الالتزام الكامل. هذه هي نقطة الدخول اليدوية الوحيدة لصناديق اختبار الإصدار الأربعة الكبيرة: Vitest، وDocker، وQA Lab، وPackage.
8. إذا فشل التحقق، أصلح على فرع الإصدار وأعد تشغيل أصغر ملف أو مسار أو مهمة workflow أو ملف تعريف حزمة أو مزود أو قائمة سماح نماذج فاشلة تثبت الإصلاح. أعد تشغيل المظلة الكاملة فقط عندما يجعل السطح المتغير الأدلة السابقة قديمة.
9. بالنسبة إلى التجريبي، وسم vYYYY.M.D-beta.N، ثم شغّل OpenClaw Release Publish من فرع release/YYYY.M.D المطابق. يتحقق من pnpm plugins:sync:check، ويرسل كل حزم Plugin القابلة للنشر إلى npm والمجموعة نفسها إلى ClawHub بالتوازي، ثم يرقّي أثر فحص ما قبل الإطلاق المُحضّر لـ OpenClaw npm باستخدام dist-tag المطابق بمجرد نجاح نشر Plugin إلى npm. بعد نجاح العملية الفرعية لنشر OpenClaw npm، ينشئ أو يحدّث صفحة GitHub release/prerelease المطابقة من قسم CHANGELOG.md المطابق الكامل. الإصدارات المستقرة المنشورة إلى npm latest تصبح أحدث إصدار على GitHub؛ أما إصدارات الصيانة المستقرة المحتفظ بها على npm beta فتُنشأ مع GitHub latest=false. قد يبقى نشر ClawHub قيد التشغيل بينما يُنشر OpenClaw npm، لكن workflow نشر الإصدار يطبع معرّفات التشغيل الفرعية فوراً. افتراضياً لا ينتظر ClawHub بعد إرساله، لذلك لا تُحجب إتاحة OpenClaw npm بسبب موافقات ClawHub الأبطأ أو عمل السجل؛ اضبط wait_for_clawhub=true عندما يجب أن يمنع ClawHub اكتمال workflow. مسار ClawHub يعيد محاولة إخفاقات تثبيت تبعيات CLI العابرة، وينشر Plugins التي اجتازت المعاينة حتى عند تقشر خلية معاينة واحدة، وينتهي بتحقق السجل لكل نسخة Plugin متوقعة بحيث تبقى عمليات النشر الجزئية مرئية وقابلة لإعادة المحاولة. بعد النشر، شغّل pnpm release:verify-beta -- YYYY.M.D-beta.N --openclaw-npm-run <run-id> --plugin-npm-run <run-id> --plugin-clawhub-run <run-id> للتحقق من GitHub prerelease، وdist-tags الخاصة بـ npm beta، وسلامة npm، ومسار التثبيت المنشور، ونسخ ClawHub الدقيقة، وآثار ClawHub، ونتائج workflows الفرعية من أمر واحد. أضف --rerun-failed-clawhub عندما يفشل sidecar الخاص بـ ClawHub فقط في مهام قابلة لإعادة المحاولة وينبغي إعادة تشغيله في مكانه. ثم شغّل قبول الحزمة بعد النشر مقابل حزمة openclaw@YYYY.M.D-beta.N أو openclaw@beta المنشورة. إذا احتاجت نسخة ما قبل إصدار مدفوعة أو منشورة إلى إصلاح، فاقتطع رقم ما قبل الإصدار المطابق التالي؛ لا تحذف ما قبل الإصدار القديم ولا تعِد كتابته.
10. بالنسبة إلى المستقر، تابع فقط بعد أن تتوفر للإصدار التجريبي المُراجع أو مرشح الإصدار أدلة التحقق المطلوبة. يمر نشر npm المستقر أيضاً عبر OpenClaw Release Publish، مع إعادة استخدام أثر فحص ما قبل الإطلاق الناجح عبر preflight_run_id؛ وتتطلب جاهزية إصدار macOS المستقر أيضاً وجود ملفات .zip و.dmg و.dSYM.zip المحزمة، وappcast.xml محدثاً على main. ينشر workflow نشر macOS الخاص appcast الموقّع إلى main العام تلقائياً بعد تحقق أصول الإصدار؛ وإذا منعت حماية الفرع الدفع المباشر، فإنه يفتح أو يحدّث PR خاصاً بـ appcast.
11. بعد النشر، شغّل متحقق ما بعد نشر npm، واختبار Telegram E2E المنشور من npm المستقل الاختياري عندما تحتاج إلى إثبات قناة بعد النشر، وترقية dist-tag عند الحاجة، وتحقق من صفحة GitHub release المولدة، وشغّل خطوات إعلان الإصدار.

​

فحص ما قبل الإصدار

• شغّل pnpm check:test-types قبل فحص ما قبل الإصدار كي تبقى TypeScript الخاصة بالاختبارات مغطاة خارج بوابة pnpm check المحلية الأسرع
• شغّل pnpm check:architecture قبل فحص ما قبل الإصدار كي تكون فحوصات دورات الاستيراد الأوسع وحدود المعمارية خضراء خارج البوابة المحلية الأسرع
• شغّل pnpm build && pnpm ui:build قبل pnpm release:check كي توجد عناصر إصدار dist/* المتوقعة وحزمة واجهة التحكم لخطوة التحقق من الحزمة
• شغّل pnpm release:prep بعد رفع إصدار الجذر وقبل الوسم. فهو يشغّل كل مولّد إصدار حتمي ينجرف عادة بعد تغيير الإصدار/الإعدادات/API: إصدارات plugin، ومخزون plugin، ومخطط الإعداد الأساسي، وبيانات إعداد القنوات المضمّنة، وخط أساس وثائق الإعداد، وتصديرات SDK الخاصة بـ plugin، وخط أساس API الخاص بـ SDK للـ plugin. يعيد pnpm release:check تشغيل تلك الحراسات في وضع الفحص ويبلّغ عن كل فشل انجراف مولّد يعثر عليه في مرور واحد قبل تشغيل فحوصات إصدار الحزمة.
• شغّل سير عمل Full Release Validation اليدوي قبل الموافقة على الإصدار لتشغيل كل صناديق اختبار ما قبل الإصدار من نقطة دخول واحدة. يقبل فرعًا، أو وسمًا، أو SHA كاملًا للالتزام، ويطلق CI يدويًا، ويطلق OpenClaw Release Checks لفحص التثبيت السريع، وقبول الحزمة، وفحوصات الحزمة عبر أنظمة التشغيل، وتكافؤ QA Lab، وMatrix، ومسارات Telegram. تحتفظ عمليات التشغيل المستقرة/الافتراضية بفحوصات live/E2E الشاملة وتشغيل Docker المطوّل لمسار الإصدار خلف run_release_soak=true؛ ويفرض release_profile=full التشغيل المطوّل. ومع release_profile=full وrerun_group=all، يشغّل أيضًا E2E لحزمة Telegram ضد عنصر release-package-under-test الناتج من فحوصات الإصدار. قدّم release_package_spec بعد نشر إصدار beta لإعادة استخدام حزمة npm المشحونة عبر فحوصات الإصدار، وPackage Acceptance، وE2E لحزمة Telegram دون إعادة بناء tarball الإصدار. قدّم npm_telegram_package_spec فقط عندما يجب أن يستخدم Telegram حزمة منشورة مختلفة عن بقية تحقق الإصدار. قدّم package_acceptance_package_spec عندما يجب أن يستخدم Package Acceptance حزمة منشورة مختلفة عن مواصفة حزمة الإصدار. قدّم evidence_package_spec عندما يجب أن يثبت تقرير الأدلة الخاص أن التحقق يطابق حزمة npm منشورة دون فرض E2E لـ Telegram. مثال: gh workflow run full-release-validation.yml --ref main -f ref=release/YYYY.M.D
• شغّل سير عمل Package Acceptance اليدوي عندما تريد إثباتًا من قناة جانبية لمرشح حزمة بينما يستمر عمل الإصدار. استخدم source=npm لـ openclaw@beta أو openclaw@latest أو إصدار محدد بدقة؛ وsource=ref لحزم فرع/وسم/SHA موثوق في package_ref باستخدام harness الحالي في workflow_ref؛ وsource=url لـ tarball عبر HTTPS مع SHA-256 مطلوب؛ أو source=artifact لـ tarball رُفع بواسطة تشغيل GitHub Actions آخر. يحل سير العمل المرشح إلى package-under-test، ويعيد استخدام مجدول إصدار Docker E2E ضد ذلك tarball، ويمكنه تشغيل QA لـ Telegram ضد tarball نفسه باستخدام telegram_mode=mock-openai أو telegram_mode=live-frontier. عندما تتضمن مسارات Docker المختارة published-upgrade-survivor، يكون عنصر الحزمة هو المرشح ويحدد published_upgrade_survivor_baseline خط الأساس المنشور. يستخدم update-restart-auth حزمة المرشح بوصفها CLI المثبتة وpackage-under-test معًا كي يمرّن مسار إعادة التشغيل المُدار لأمر التحديث الخاص بالمرشح. مثال: gh workflow run package-acceptance.yml --ref main -f workflow_ref=main -f source=npm -f package_spec=openclaw@beta -f suite_profile=product -f published_upgrade_survivor_baseline=openclaw@2026.4.26 -f telegram_mode=mock-openai ملفات التعريف الشائعة:
  • smoke: مسارات التثبيت/القناة/الوكيل، وشبكة Gateway، وإعادة تحميل الإعدادات
  • package: مسارات الحزمة/التحديث/إعادة التشغيل/plugin الأصلية للعنصر دون OpenWebUI أو ClawHub مباشر
  • product: ملف تعريف الحزمة إضافة إلى قنوات MCP، وتنظيف cron/subagent، وبحث الويب من OpenAI، وOpenWebUI
  • full: أجزاء مسار إصدار Docker مع OpenWebUI
  • custom: اختيار docker_lanes بدقة لإعادة تشغيل مركزة
• شغّل سير عمل CI اليدوي مباشرة عندما تحتاج فقط إلى تغطية CI عادية كاملة لمرشح الإصدار. تتجاوز عمليات إطلاق CI اليدوية نطاق التغييرات وتفرض شظايا Linux Node، وشظايا plugin المضمّنة، وعقود القنوات، وتوافق Node 22، وcheck، وcheck-additional، وفحص البناء السريع، وفحوصات الوثائق، وSkills الخاصة بـ Python، وWindows، وmacOS، وAndroid، ومسارات i18n لواجهة التحكم. مثال: gh workflow run ci.yml --ref release/YYYY.M.D
• شغّل pnpm qa:otel:smoke عند التحقق من قياسات الإصدار. فهو يمرّن QA-lab عبر مستقبل OTLP/HTTP محلي ويتحقق من أسماء spans الأثر المصدّرة، والسمات المحدودة، وتنقيح المحتوى/المعرّفات دون طلب Opik أو Langfuse أو جامع خارجي آخر.
• شغّل pnpm release:check قبل كل إصدار موسوم
• شغّل OpenClaw Release Publish لتسلسل النشر المُعدِّل بعد وجود الوسم. أطلقه من release/YYYY.M.D (أو main عند نشر وسم قابل للوصول من main)، ومرّر وسم الإصدار وpreflight_run_id ناجحًا لـ OpenClaw npm، وأبقِ نطاق نشر plugin الافتراضي all-publishable ما لم تكن تشغّل إصلاحًا مركّزًا عمدًا. ينسّق سير العمل نشر plugin إلى npm، ونشر plugin إلى ClawHub، ونشر OpenClaw إلى npm بحيث لا تُنشر الحزمة الأساسية قبل plugins الخارجية الخاصة بها.
• تعمل فحوصات الإصدار الآن في سير عمل يدوي منفصل: OpenClaw Release Checks
• يشغّل OpenClaw Release Checks أيضًا مسار تكافؤ QA Lab الوهمي إضافة إلى ملف تعريف Matrix المباشر السريع ومسار QA لـ Telegram قبل الموافقة على الإصدار. تستخدم المسارات المباشرة بيئة qa-live-shared؛ ويستخدم Telegram أيضًا تأجيرات بيانات اعتماد Convex CI. شغّل سير عمل QA-Lab - All Lanes اليدوي مع matrix_profile=all وmatrix_shards=true عندما تريد مخزون نقل Matrix والوسائط وE2EE كاملًا بالتوازي.
• يُعد تحقق وقت التشغيل للتثبيت والترقية عبر أنظمة التشغيل جزءًا من OpenClaw Release Checks وFull Release Validation العامين، اللذين يستدعيان سير العمل القابل لإعادة الاستخدام .github/workflows/openclaw-cross-os-release-checks-reusable.yml مباشرة
• هذا الفصل مقصود: أبقِ مسار إصدار npm الحقيقي قصيرًا، وحتميًا، ومركّزًا على العناصر، بينما تبقى الفحوصات المباشرة الأبطأ في مسارها الخاص حتى لا تؤخر النشر أو تمنعه
• يجب إطلاق فحوصات الإصدار الحاملة للأسرار عبر Full Release Validation أو من مرجع سير عمل main/release كي تبقى منطق سير العمل والأسرار مضبوطة
• يقبل OpenClaw Release Checks فرعًا، أو وسمًا، أو SHA كاملًا للالتزام ما دام الالتزام المحلول قابلًا للوصول من فرع OpenClaw أو وسم إصدار
• يقبل فحص ما قبل الإصدار التحققي فقط في OpenClaw NPM Release أيضًا SHA الحالي الكامل ذي 40 حرفًا لالتزام فرع سير العمل دون طلب وسم مدفوع
• مسار SHA هذا للتحقق فقط ولا يمكن ترقيته إلى نشر حقيقي
• في وضع SHA، يصطنع سير العمل v<package.json version> فقط لفحص بيانات الحزمة الوصفية؛ لا يزال النشر الحقيقي يتطلب وسم إصدار حقيقيًا
• يحافظ كلا سيري العمل على مسار النشر والترقية الحقيقي على مشغلات GitHub-hosted، بينما يمكن لمسار التحقق غير المُعدِّل استخدام مشغلات Blacksmith Linux الأكبر
• يشغّل سير العمل هذا OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache باستخدام سرّي سير العمل OPENAI_API_KEY وANTHROPIC_API_KEY
• لم يعد فحص ما قبل إصدار npm ينتظر مسار فحوصات الإصدار المنفصل
• قبل وسم مرشح إصدار محليًا، شغّل RELEASE_TAG=vYYYY.M.D-beta.N pnpm release:fast-pretag-check. يشغّل المساعد حواجز الإصدار السريعة، وفحوصات إصدار plugin إلى npm/ClawHub، والبناء، وبناء الواجهة، وrelease:openclaw:npm:check بالترتيب الذي يلتقط الأخطاء الشائعة الحاجبة للموافقة قبل بدء سير عمل النشر في GitHub.
• شغّل RELEASE_TAG=vYYYY.M.D node --import tsx scripts/openclaw-npm-release-check.ts (أو وسم beta/التصحيح المطابق) قبل الموافقة
• بعد نشر npm، شغّل node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.D (أو إصدار beta/التصحيح المطابق) للتحقق من مسار تثبيت السجل المنشور في بادئة مؤقتة جديدة
• بعد نشر beta، شغّل OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@YYYY.M.D-beta.N OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci pnpm test:docker:npm-telegram-live للتحقق من تمهيد الحزمة المثبتة، وإعداد Telegram، وE2E حقيقي لـ Telegram ضد حزمة npm المنشورة باستخدام مخزون بيانات اعتماد Telegram المؤجرة المشتركة. يمكن لعمليات الصيانة المحلية لمرة واحدة حذف متغيرات Convex وتمرير بيانات اعتماد البيئة الثلاث OPENCLAW_QA_TELEGRAM_* مباشرة.
• لتشغيل فحص beta السريع الكامل بعد النشر من جهاز مشرف صيانة، استخدم pnpm release:beta-smoke -- --beta betaN. يشغّل المساعد تحقق Parallels لتحديث npm/هدف جديد، ويطلق NPM Telegram Beta E2E، ويستطلع تشغيل سير العمل الدقيق، وينزّل العنصر، ويطبع تقرير Telegram.
• يمكن لمشرفي الصيانة تشغيل الفحص نفسه بعد النشر من GitHub Actions عبر سير عمل NPM Telegram Beta E2E اليدوي. وهو يدوي فقط عن قصد ولا يعمل مع كل دمج.
• تستخدم أتمتة إصدار مشرفي الصيانة الآن نمط فحص ما قبل الإصدار ثم الترقية:
  • يجب أن يمر نشر npm الحقيقي عبر preflight_run_id ناجح لـ npm
  • يجب إطلاق نشر npm الحقيقي من فرع main أو release/YYYY.M.D نفسه الذي شُغّل منه فحص ما قبل الإصدار الناجح
  • تستهدف إصدارات npm المستقرة beta افتراضيًا
  • يمكن لنشر npm المستقر استهداف latest صراحة عبر مُدخل سير العمل
  • بات تعديل dist-tag الخاص بـ npm المستند إلى الرمز المميز موجودًا الآن في openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml للأمان، لأن npm dist-tag add لا يزال يحتاج إلى NPM_TOKEN بينما يحافظ المستودع العام على النشر عبر OIDC فقط
  • إصدار macOS Release العام للتحقق فقط؛ عندما يوجد وسم فقط على فرع إصدار لكن سير العمل يُطلق من main، اضبط public_release_branch=release/YYYY.M.D
  • يجب أن يمر نشر mac الخاص الحقيقي عبر preflight_run_id وvalidate_run_id ناجحين خاصين بـ mac
  • تروّج مسارات النشر الحقيقي العناصر المُحضّرة بدلًا من إعادة بنائها مرة أخرى
• بالنسبة إلى إصدارات التصحيح المستقرة مثل YYYY.M.D-N، يتحقق مُثبت ما بعد النشر أيضًا من مسار الترقية نفسه ببادئة مؤقتة من YYYY.M.D إلى YYYY.M.D-N حتى لا تترك تصحيحات الإصدار التثبيتات العمومية الأقدم صامتة على حمولة الإصدار المستقر الأساسي
• يفشل فحص ما قبل إصدار npm على نحو مغلق ما لم يتضمن tarball كلا من dist/control-ui/index.html وحمولة غير فارغة في dist/control-ui/assets/ حتى لا نشحن لوحة متصفح فارغة مرة أخرى
• يتحقق تحقق ما بعد النشر أيضًا من وجود نقاط دخول plugin المنشورة وبيانات الحزمة الوصفية في تخطيط السجل المثبت. يفشل أي إصدار يشحن حمولات وقت تشغيل plugin مفقودة في مُثبت ما بعد النشر ولا يمكن ترقيته إلى latest.
• يفرض pnpm test:install:smoke أيضًا ميزانية unpackedSize الخاصة بحزمة npm على tarball تحديث المرشح، بحيث يلتقط installer e2e تضخم الحزمة العرضي قبل مسار نشر الإصدار
• إذا لمس عمل الإصدار تخطيط CI، أو بيانات توقيت plugin، أو مصفوفات اختبار plugin، فأعد توليد ومراجعة مخرجات مصفوفة plugin-prerelease-extension-shard المملوكة للمخطط من .github/workflows/plugin-prerelease.yml قبل الموافقة حتى لا تصف ملاحظات الإصدار تخطيط CI قديمًا
• تتضمن جاهزية إصدار macOS المستقر أيضًا أسطح المحدّث:
  • يجب أن ينتهي إصدار GitHub باحتواء .zip و.dmg و.dSYM.zip المعبأة
  • يجب أن يشير appcast.xml على main إلى zip المستقر الجديد بعد النشر؛ يثبته سير عمل نشر macOS الخاص تلقائيًا، أو يفتح PR لـ appcast عندما يكون الدفع المباشر محظورًا
  • يجب أن يحافظ التطبيق المعبأ على bundle id غير تصحيحي، وURL تغذية Sparkle غير فارغ، وCFBundleVersion عند حد البناء الأساسي القانوني لـ Sparkle لذلك الإصدار أو أعلى منه

​

صناديق اختبار الإصدار

pnpm ci:full-release --sha <full-sha>

gh workflow run full-release-validation.yml \
  --ref main \
  -f ref=release/YYYY.M.D \
  -f provider=openai \
  -f mode=both \
  -f release_profile=stable \
  -f evidence_package_spec=openclaw@YYYY.M.D-beta.N

• minimum: أسرع مسار OpenAI/core live وDocker حرج للإصدار
• stable: الحد الأدنى مع تغطية stable provider/backend لاعتماد الإصدار
• full: stable مع تغطية advisory provider/media واسعة

# Validate an unpublished release candidate branch.
gh workflow run full-release-validation.yml \
  --ref main \
  -f ref=release/YYYY.M.D \
  -f provider=openai \
  -f mode=both \
  -f release_profile=stable

# Validate an exact pushed commit.
gh workflow run full-release-validation.yml \
  --ref main \
  -f ref=<40-char-sha> \
  -f provider=openai \
  -f mode=both

# After publishing a beta, add published-package Telegram E2E.
gh workflow run full-release-validation.yml \
  --ref main \
  -f ref=release/YYYY.M.D \
  -f provider=openai \
  -f mode=both \
  -f release_profile=full \
  -f release_package_spec=openclaw@YYYY.M.D-beta.N \
  -f evidence_package_spec=openclaw@YYYY.M.D-beta.N \
  -f npm_telegram_provider_mode=mock-openai

​

Vitest

• ملخص Full Release Validation الذي يعرض رابط تشغيل CI المشغّل
• تشغيل CI أخضر على SHA الهدف الدقيق
• أسماء التقسيمات الفاشلة أو البطيئة من مهام CI عند التحقيق في التراجعات
• آثار توقيت Vitest مثل .artifacts/vitest-shard-timings.json عندما يحتاج التشغيل إلى تحليل الأداء

gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.D

​

Docker

• smoke تثبيت كامل مع تمكين smoke التثبيت العالمي البطيء لـ Bun
• إعداد/إعادة استخدام صورة smoke لـ Dockerfile الجذري بحسب SHA الهدف، مع تشغيل مهام QR، وroot/gateway، وinstaller/Bun smoke كتقسيمات install-smoke منفصلة
• مسارات E2E للمستودع
• أجزاء Docker لمسار الإصدار: core، وpackage-update-openai، وpackage-update-anthropic، وpackage-update-core، وplugins-runtime-plugins، وplugins-runtime-services، وplugins-runtime-install-a، وplugins-runtime-install-b، وplugins-runtime-install-c، وplugins-runtime-install-d، وplugins-runtime-install-e، وplugins-runtime-install-f، وplugins-runtime-install-g، وplugins-runtime-install-h
• تغطية OpenWebUI داخل جزء plugins-runtime-services عند الطلب
• مسارات تثبيت/إلغاء تثبيت Plugin المضمّنة المقسّمة bundled-plugin-install-uninstall-0 حتى bundled-plugin-install-uninstall-23
• مجموعات live/E2E provider وتغطية Docker live model عندما تتضمن فحوصات الإصدار مجموعات live

​

QA Lab

• مسار تكافؤ mock يقارن مسار OpenAI المرشح مع أساس Opus 4.6 باستخدام حزمة التكافؤ agentic
• ملف QA live Matrix سريع باستخدام بيئة qa-live-shared
• مسار QA حي لـ Telegram باستخدام إيجارات بيانات اعتماد Convex CI
• pnpm qa:otel:smoke عندما يحتاج telemetry الإصدار إلى إثبات محلي صريح

​

Package

• source=npm: openclaw@beta، أو openclaw@latest، أو إصدار OpenClaw دقيق من الإصدار
• source=ref: حزم فرع package_ref أو وسم أو SHA commit كامل موثوق مع حزمة workflow_ref المحددة
• source=url: تنزيل .tgz عبر HTTPS مع package_sha256 مطلوب
• source=artifact: إعادة استخدام .tgz مرفوع بواسطة تشغيل GitHub Actions آخر

gh workflow run package-acceptance.yml \
  --ref main \
  -f workflow_ref=main \
  -f source=npm \
  -f package_spec=openclaw@beta \
  -f suite_profile=product \
  -f published_upgrade_survivor_baseline=openclaw@2026.4.26

• smoke: مسارات سريعة لتثبيت الحزمة/القناة/الوكيل، وشبكة Gateway، وإعادة تحميل الإعدادات
• package: عقود تثبيت/تحديث/إعادة تشغيل/حزمة Plugin إضافة إلى دليل تثبيت Skills مباشر من ClawHub؛ هذا هو الإعداد الافتراضي لفحص الإصدار
• product: package إضافة إلى قنوات MCP، وتنظيف cron/subagent، وبحث الويب من OpenAI، وOpenWebUI
• full: أجزاء مسار إصدار Docker مع OpenWebUI
• custom: قائمة docker_lanes دقيقة لإعادات تشغيل مركزة

​

أتمتة نشر الإصدار

1. سحب وسم الإصدار وحل SHA الخاص بالتزامه.
2. التحقق من إمكانية الوصول إلى الوسم من main أو release/*.
3. تشغيل pnpm plugins:sync:check.
4. إطلاق Plugin NPM Release باستخدام publish_scope=all-publishable و ref=<release-sha>.
5. إطلاق Plugin ClawHub Release بالنطاق نفسه وSHA نفسه.
6. إطلاق OpenClaw NPM Release بوسم الإصدار، ووسم توزيع npm، و preflight_run_id المحفوظ.

gh workflow run openclaw-release-publish.yml \
  --ref release/YYYY.M.D \
  -f tag=vYYYY.M.D-beta.N \
  -f preflight_run_id=<successful-openclaw-npm-preflight-run-id> \
  -f npm_dist_tag=beta

gh workflow run openclaw-release-publish.yml \
  --ref release/YYYY.M.D \
  -f tag=vYYYY.M.D \
  -f preflight_run_id=<successful-openclaw-npm-preflight-run-id> \
  -f npm_dist_tag=beta

gh workflow run openclaw-release-publish.yml \
  --ref release/YYYY.M.D \
  -f tag=vYYYY.M.D \
  -f preflight_run_id=<successful-openclaw-npm-preflight-run-id> \
  -f npm_dist_tag=latest

​

مُدخلات سير عمل NPM

• tag: وسم إصدار مطلوب مثل v2026.4.2، أو v2026.4.2-1، أو v2026.4.2-beta.1؛ عندما تكون preflight_only=true، قد يكون أيضا SHA الالتزام الكامل الحالي بطول 40 حرفا لفرع سير العمل من أجل الفحص التمهيدي المخصص للتحقق فقط
• preflight_only: القيمة true للتحقق/البناء/الحزم فقط، وfalse لمسار النشر الحقيقي
• preflight_run_id: مطلوب في مسار النشر الحقيقي حتى يعيد سير العمل استخدام ملف tarball المُحضّر من تشغيل الفحص التمهيدي الناجح
• npm_dist_tag: وسم npm المستهدف لمسار النشر؛ القيمة الافتراضية beta

• tag: وسم إصدار مطلوب؛ يجب أن يكون موجودا مسبقا
• preflight_run_id: معرّف تشغيل فحص تمهيدي ناجح لـOpenClaw NPM Release؛ مطلوب عندما تكون publish_openclaw_npm=true
• npm_dist_tag: وسم npm المستهدف لحزمة OpenClaw
• plugin_publish_scope: القيمة الافتراضية all-publishable؛ استخدم selected فقط لأعمال الإصلاح المركزة
• plugins: أسماء حزم @openclaw/* مفصولة بفواصل عندما تكون plugin_publish_scope=selected
• publish_openclaw_npm: القيمة الافتراضية true؛ اضبطها إلى false فقط عند استخدام سير العمل كمنسق إصلاح خاص بـPlugin فقط
• wait_for_clawhub: القيمة الافتراضية false بحيث لا يحجب توفر npm المسار الجانبي ClawHub؛ اضبطها إلى true فقط عندما يجب أن يتضمن اكتمال سير العمل اكتمال ClawHub

• ref: فرع أو وسم أو SHA التزام كامل للتحقق منه. تتطلب الفحوصات الحاملة للأسرار أن يكون الالتزام الذي تم حله قابلا للوصول من فرع OpenClaw أو وسم إصدار.
• run_release_soak: الاشتراك في فحوصات soak الشاملة للحية/E2E، ومسار إصدار Docker، وكل upgrade-survivor منذ البداية على فحوصات الإصدار المستقرة/الافتراضية. يتم فرضه بواسطة release_profile=full.

• يمكن نشر وسوم الإصدارات المستقرة والتصحيحية إلى beta أو latest
• يمكن نشر وسوم إصدارات beta التمهيدية إلى beta فقط
• بالنسبة إلى OpenClaw NPM Release، يُسمح بإدخال SHA الالتزام الكامل فقط عندما تكون preflight_only=true
• OpenClaw Release Checks وFull Release Validation مخصصان دائما للتحقق فقط
• يجب أن يستخدم مسار النشر الحقيقي npm_dist_tag نفسه المستخدم أثناء الفحص التمهيدي؛ ويتحقق سير العمل من تلك البيانات الوصفية قبل متابعة النشر

​

تسلسل إصدار npm مستقر

1. شغّل OpenClaw NPM Release مع preflight_only=true
   • قبل وجود وسم، يمكنك استخدام SHA الالتزام الكامل الحالي لفرع سير العمل كتجربة جافة مخصصة للتحقق فقط من سير عمل الفحص التمهيدي
2. اختر npm_dist_tag=beta للتدفق المعتاد الذي يبدأ بـbeta، أو latest فقط عندما تريد عمدا نشرا مستقرا مباشرا
3. شغّل Full Release Validation على فرع الإصدار أو وسم الإصدار أو SHA الالتزام الكامل عندما تريد CI المعتاد إضافة إلى تغطية live prompt cache وDocker وQA Lab وMatrix وTelegram من سير عمل يدوي واحد
4. إذا كنت تحتاج عمدا إلى رسم الاختبار الطبيعي الحتمي فقط، فشغّل سير عمل CI اليدوي على مرجع الإصدار بدلا من ذلك
5. احفظ preflight_run_id الناجح
6. شغّل OpenClaw Release Publish باستخدام tag نفسه وnpm_dist_tag نفسه وpreflight_run_id المحفوظ؛ ينشر Plugins الخارجية إلى npm وClawHub قبل ترقية حزمة OpenClaw على npm
7. إذا وصل الإصدار إلى beta، فاستخدم سير العمل الخاص openclaw/releases-private/.github/workflows/openclaw-npm-dist-tags.yml لترقية ذلك الإصدار المستقر من beta إلى latest
8. إذا نُشر الإصدار عمدا مباشرة إلى latest ويجب أن يتبع beta البناء المستقر نفسه فورا، فاستخدم سير العمل الخاص نفسه لتوجيه وسمي التوزيع إلى الإصدار المستقر، أو اترك مزامنة الإصلاح الذاتي المجدولة تنقل beta لاحقا

​

المراجع العامة

• .github/workflows/full-release-validation.yml
• .github/workflows/package-acceptance.yml
• .github/workflows/openclaw-npm-release.yml
• .github/workflows/openclaw-release-checks.yml
• .github/workflows/openclaw-cross-os-release-checks-reusable.yml
• scripts/resolve-openclaw-package-candidate.mjs
• scripts/openclaw-npm-release-check.ts
• scripts/package-mac-dist.sh
• scripts/make_appcast.sh

​

ذات صلة

• قنوات الإصدار