OpenClawDocs
View as MarkdownView this page as plain textOpen in ChatGPTAsk questions about this pageOpen in ClaudeAsk questions about this page

Release and CI

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

يعرض OpenClaw حاليًا ثلاث قنوات تحديث موجّهة للمستخدمين:

  • المستقرة: قناة الإصدار المُروَّج الحالية، التي لا تزال تُحلّ عبر latest في npm إلى أن يكتمل الإنجاز المرحلي المنفصل الخاص بـ CLI/القناة
  • التجريبية: وسوم الإصدارات التمهيدية التي تُنشر إلى beta في npm
  • التطويرية: الرأس المتحرك للفرع main

وبشكل منفصل، يمكن لمشغّلي الإصدار نشر حزمة النواة للشهر المكتمل السابق إلى extended-stable في npm، بدءًا من التصحيح 33. يستمر مسار الإصدار النهائي الاعتيادي للشهر الحالي على latest في npm؛ ولا يغيّر فصل النشر هذا من جانب المشغّل، بحد ذاته، آلية تحديد قناة التحديث في CLI.

إصدارات Tideclaw ألفا هي مسار تمهيدي داخلي منفصل (وسم توزيع npm‏ alpha)، وتغطيها فقرتا مدخلات سير عمل NPM وصناديق اختبار الإصدار.

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

  • إصدار npm الشهري الممتد الاستقرار: YYYY.M.PATCH، حيث PATCH >= 33، ووسم git هو vYYYY.M.PATCH
  • إصدار نهائي يومي/اعتيادي: YYYY.M.PATCH، حيث PATCH < 33، ووسم git هو vYYYY.M.PATCH
  • إصدار تصحيحي احتياطي اعتيادي: YYYY.M.PATCH-N، ووسم git هو vYYYY.M.PATCH-N
  • إصدار تمهيدي تجريبي: YYYY.M.PATCH-beta.N، ووسم git هو vYYYY.M.PATCH-beta.N
  • إصدار تمهيدي ألفا: YYYY.M.PATCH-alpha.N، ووسم git هو vYYYY.M.PATCH-alpha.N
  • لا تُضِف أصفارًا بادئة إلى الشهر أو التصحيح مطلقًا
  • يمثّل PATCH رقمًا تسلسليًا لمسار إصدارات شهري، وليس يومًا تقويميًا. تُقدِّم الإصدارات النهائية الاعتيادية والتجريبية المسار الحالي؛ أما وسوم ألفا فقط فلا تستهلك رقم التصحيح التجريبي/الاعتيادي ولا تُقدِّمه، لذا تجاهل وسوم ألفا القديمة فقط ذات أرقام التصحيح الأعلى عند اختيار مسار تجريبي أو اعتيادي.
  • تستخدم إصدارات ألفا/الليلية مسار التصحيح التالي الذي لم يُصدر بعد، ولا تزيد سوى alpha.N للإصدارات المتكررة. وبمجرد أن يحصل ذلك التصحيح على إصدار تجريبي، تنتقل إصدارات ألفا الجديدة إلى التصحيح التالي.
  • إصدارات npm غير قابلة للتغيير: لا تحذف وسمًا منشورًا أو تعِد نشره أو استخدامه مطلقًا. أنشئ بدلًا منه رقم الإصدار التمهيدي التالي أو التصحيح الشهري التالي.
  • يستمر latest في اتباع مسار npm الاعتيادي/اليومي الحالي؛ ويمثّل beta هدف التثبيت التجريبي الحالي
  • يعني extended-stable حزمة npm المدعومة للشهر السابق، بدءًا من التصحيح 33؛ وتكون التصحيحات 34 وما بعدها إصدارات صيانة على ذلك المسار الشهري
  • تُنشر الإصدارات النهائية الاعتيادية والإصدارات التصحيحية الاعتيادية إلى beta في npm افتراضيًا؛ ويمكن لمشغّلي الإصدار استهداف latest صراحةً، أو ترقية إصدار تجريبي خضع للتدقيق لاحقًا
  • ينشر المسار الشهري المخصص الممتد الاستقرار حزمة نواة npm وكل Plugin رسمي قابل للنشر إلى npm بالإصدار المطابق نفسه تمامًا. ولا ينشر Plugins إلى ClawHub، ولا عناصر macOS أو Windows، ولا إصدار GitHub، ولا وسوم توزيع المستودعات الخاصة، ولا صور Docker، ولا عناصر الأجهزة المحمولة، ولا تنزيلات الموقع الإلكتروني.
  • يشحن كل إصدار نهائي اعتيادي حزمة npm وتطبيق macOS وحزمة APK مستقلة موقّعة لنظام Android ومثبّتات Windows Hub الموقّعة معًا. تتحقق الإصدارات التجريبية عادةً من مسار npm/الحزمة وتنشره أولًا، بينما يقتصر بناء التطبيقات الأصلية وتوقيعها وتوثيقها وترقيتها على الإصدار النهائي الاعتيادي ما لم يُطلب ذلك صراحةً.

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

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

نشر npm الشهري الممتد الاستقرار فقط

هذا استثناء مخصص من إجراء الإصدار الاعتيادي أدناه. بالنسبة إلى شهر مكتمل YYYY.M، أنشئ extended-stable/YYYY.M.33؛ وانشر vYYYY.M.33 وتصحيحات الصيانة اللاحقة من الفرع نفسه. يجب أن يحدد كل من وسم الإصدار ورأس الفرع ونسخة العمل وإصدار الحزمة وفحص npm التمهيدي وتشغيل التحقق الكامل من الإصدار الالتزام نفسه. يجب أن يحتوي main المحمي مسبقًا على إصدار نهائي لشهر تقويمي لاحق بشكل صارم وبتصحيح أقل من 33؛ وتظل تصحيحات الصيانة مؤهلة بعد تقدّم main بأكثر من شهر واحد.

على فرع الممتد الاستقرار المحدد، ارفع إصدار الحزمة الجذرية إلى YYYY.M.P، وشغّل pnpm release:prep، وتحقق من أن كل حزمة امتداد قابلة للنشر تحمل الإصدار نفسه. ثبّت كل التغييرات المُنشأة وادفعها، وأنشئ وادفع الوسم غير القابل للتغيير vYYYY.M.P عند ذلك الالتزام، وسجّل قيمة SHA الكاملة الناتجة. تستهلك مسارات العمل هذه الشجرة المُعدّة؛ ولا ترفع الإصدارات أو تزامنها نيابةً عنك.

شغّل فحص npm التمهيدي والتحقق الكامل من الإصدار من رأس الفرع المُعدّ نفسه تمامًا، ثم احفظ معرّفي التشغيل ومحاولة تشغيل التحقق الكامل من الإصدار الناجحة:

bash
gh workflow run openclaw-npm-release.yml \  --ref extended-stable/YYYY.M.33 \  -f tag=vYYYY.M.P \  -f preflight_only=true \  -f npm_dist_tag=extended-stable gh workflow run full-release-validation.yml \  --ref extended-stable/YYYY.M.33 \  -f ref=extended-stable/YYYY.M.33 \  -f release_profile=stable

يمثّل release_profile=stable ملف عمق التحقق الحالي؛ وهو منفصل عن وسم توزيع npm‏ extended-stable، ولم يتغير عمدًا.

بعد نجاح التشغيلين، انشر كل Plugin رسمي قابل للنشر إلى npm من رأس الفرع نفسه تمامًا. يجب أن يكون التصحيح P مساويًا لـ 33 أو أكبر. مرّر قيمة SHA الكاملة للإصدار بوصفها ref، وانتظر اكتمال المصفوفة وقراءة السجل اللاحقة، ثم احفظ معرّف تشغيل إصدار NPM للـ Plugin الناجح:

bash
RELEASE_SHA="$(git rev-parse HEAD)"gh workflow run plugin-npm-release.yml \  --ref extended-stable/YYYY.M.33 \  -f publish_scope=all-publishable \  -f ref="$RELEASE_SHA" \  -f npm_dist_tag=extended-stable

يستخدم سير العمل مخزون الحزم الاعتيادي المُعدّ all-publishable، بما في ذلك الحزم التي لم يتغير مصدرها. ويتحقق من كل حزمة مطابقة ومن كل وسم Plugin باسم extended-stable قبل النجاح. إذا فشل تشغيل جزئي، فأعد تشغيل الأمر نفسه: يُعاد استخدام الحزم المنشورة مسبقًا، وتُسوّى وسوم Plugins المفقودة أو القديمة ضمن بيئة إصدار npm، وتظل القراءة اللاحقة النهائية تغطي مجموعة الحزم الكاملة.

بعد نجاح سير عمل Plugins وجاهزية بيئة إصدار npm، انشر ملف tarball الأساسي المطابق من الفحص التمهيدي. يتحقق نشر النواة من أن تشغيل Plugins المُشار إليه في حالة completed/success على الفرع القياسي نفسه وقيمة SHA المصدر المطابقة تمامًا:

bash
gh workflow run openclaw-npm-release.yml \  --ref extended-stable/YYYY.M.33 \  -f tag=vYYYY.M.P \  -f preflight_only=false \  -f npm_dist_tag=extended-stable \  -f preflight_run_id=<npm-preflight-run-id> \  -f full_release_validation_run_id=<full-validation-run-id> \  -f full_release_validation_run_attempt=<full-validation-run-attempt> \  -f plugin_npm_run_id=<plugin-npm-run-id>

بالنسبة إلى نسخة متفرعة أو تجربة غير إنتاجية يتعذر عليها عمدًا استيفاء سياسة الشهر .33 أو سياسة شهر main المحمي، أضف -f bypass_extended_stable_guard=true إلى عمليتي إرسال فحص npm التمهيدي والنشر. القيمة الافتراضية هي false. لا يُقبل التجاوز إلا مع npm_dist_tag=extended-stable، ويُسجّل في ملخص سير العمل. ولا يتجاوز مرجع سير العمل القياسي extended-stable/YYYY.M.33، أو تطابق رأس الفرع/الوسم/نسخة العمل، أو صياغة الوسم النهائي، أو تطابق إصدار الحزمة/الوسم، أو هوية التشغيل والبيان المُشار إليهما، أو منشأ ملف tarball، أو موافقة البيئة، أو القراءة اللاحقة للسجل، أو دليل إصلاح أداة التحديد.

يتحقق سير عمل النشر من هويات الفحص التمهيدي والتحقق وتشغيل Plugins المُشار إليها، ومن بصمة ملف tarball المُعدّ، ومن أدوات تحديد سجل النواة. أكّد النتيجة بصورة مستقلة بعد نجاح سير العمل:

bash
npm view openclaw@YYYY.M.P version --userconfig "$(mktemp)"npm view openclaw@extended-stable version --userconfig "$(mktemp)"

يجب أن يُرجع كلا الأمرين YYYY.M.P. إذا نجح النشر لكن فشلت القراءة اللاحقة لأداة التحديد، فلا تعِد نشر إصدار الحزمة غير القابل للتغيير. استخدم أمر الإصلاح الوحيد npm dist-tag add openclaw@YYYY.M.P extended-stable المطبوع في الملخص دائم التشغيل لسير العمل الفاشل، ثم كرر القراءتين اللاحقتين المستقلتين. تُعد العودة إلى أداة التحديد السابقة قرارًا منفصلًا للمشغّل، وليست مسار إصلاح القراءة اللاحقة.

تحدد وثائق الدعم العامة مبدئيًا Slack وDiscord وCodex بوصفها أسطح Plugins التي يغطيها الممتد الاستقرار. هذه القائمة بيان دعم وليست قائمة سماح في شيفرة الإصدار: يتبع كل Plugin رسمي قابل للنشر إلى npm مسار النشر نفسه ذي الإصدار المطابق تمامًا.

تظل قائمة التحقق الاعتيادية أدناه مسؤولة عن الإصدارات التجريبية وlatest وإصدار GitHub وPlugins وmacOS وWindows ومنشورات المنصات الأخرى. لا تنفّذ تلك الخطوات لهذا المسار الممتد الاستقرار الخاص بـ npm فقط.

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

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

  1. ابدأ من main الحالي: اسحب أحدث التغييرات، وتأكد من دفع الالتزام المستهدف، وتأكد من أن حالة CI لفرع main سليمة بما يكفي لإنشاء فرع منه.

  2. أنشئ القسم العلوي من CHANGELOG.md من طلبات السحب المدمجة وجميع الالتزامات المباشرة منذ آخر وسم إصدار يمكن الوصول إليه. اجعل الإدخالات موجهة للمستخدم، وأزل التكرار بين إدخالات طلبات السحب والالتزامات المباشرة المتداخلة، ثم نفّذ الالتزام والدفع، وأعد تنفيذ إعادة التأسيس/السحب مرة أخرى قبل إنشاء الفرع. عندما يعيد وسم إصدار متشعب أو نقل لاحق إلى الأمام ربط طلبات سحب سبق إصدارها، مرّر ذلك الوسم صراحةً باستخدام --shipped-ref؛ يستخدم المتحقق صفوف طلبات السحب الصريحة من سجلات المساهمات الكاملة في الأقسام المرقمة من لقطة الوسم، ويتجاهل Unreleased، ويسجل قائمة طلبات السحب المستبعدة وعددها بدقة.

  3. راجع سجلات توافق الإصدار في src/plugins/compat/registry.ts وsrc/commands/doctor/shared/deprecation-compat.ts. أزل التوافق المنتهي فقط عندما يظل مسار الترقية مشمولًا، أو سجّل سبب الاحتفاظ به عمدًا.

  4. أنشئ release/YYYY.M.PATCH من main الحالي. لا تنفّذ أعمال الإصدار المعتادة مباشرةً على main.

  5. حدّث كل موضع إصدار مطلوب للوسم، ثم شغّل pnpm release:prep. يحدّث هذا، بالترتيب، إصدارات plugins، وملفات تقليص npm، وقائمة plugins، ومخطط الإعداد الأساسي، وبيانات إعداد القنوات المضمّنة، وخط أساس وثائق الإعداد، وصادرات حزمة تطوير Plugin، وخط أساس واجهة برمجة تطبيقات حزمة تطوير Plugin. نفّذ التزامًا لأي انحراف مولّد قبل وضع الوسم، ثم شغّل الفحص التمهيدي المحلي الحتمي: pnpm check:test-types، وpnpm check:architecture، وpnpm build && pnpm ui:build، وpnpm release:check.

  6. شغّل OpenClaw NPM Release مع preflight_only=true. قبل وجود الوسم، يُسمح باستخدام SHA كامل بطول 40 محرفًا لفرع الإصدار لإجراء الفحص التمهيدي المخصص للتحقق فقط. يولّد الفحص التمهيدي أدلة إصدار التبعيات للرسم البياني الدقيق للتبعيات المسحوب حاليًا ويخزنها في أثر الفحص التمهيدي لـ npm. احفظ قيمة preflight_run_id الناجحة.

  7. ابدأ جميع اختبارات ما قبل الإصدار باستخدام Full Release Validation لفرع الإصدار أو الوسم أو SHA الكامل للالتزام. هذه هي نقطة الدخول اليدوية الوحيدة لمجموعات اختبارات الإصدار الأربع الكبرى: Vitest وDocker وQA Lab والحزمة. احفظ full_release_validation_run_id والقيمة الدقيقة لـ full_release_validation_run_attempt؛ فكلاهما مدخل مطلوب لـ OpenClaw NPM Release وOpenClaw Release Publish.

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

  9. لمرشح بيتا موسوم، شغّل pnpm release:candidate -- --tag vYYYY.M.PATCH-beta.N من فرع release/YYYY.M.PATCH المطابق. وللإصدار المستقر، مرّر أيضًا إصدار مصدر Windows المطلوب: pnpm release:candidate -- --tag vYYYY.M.PATCH --windows-node-tag vX.Y.Z. تستخدم الأداة المساعدة main الموثوق به مصدرًا لسير العمل، بينما يستهدف كل سير عمل الوسم الدقيق. تسجل هوية المرشح/الأدوات غير القابلة للتغيير ومعرّفات التشغيلات المُرسلة في .artifacts/release-candidate/<tag>/release-candidate-state.json؛ وتؤدي إعادة تشغيل الأمر نفسه إلى استئناف تلك التشغيلات نفسها بدقة، بينما يؤدي أي انحراف في المرشح أو الأدوات أو ملف التعريف أو الخيارات إلى الفشل المغلق. قبل إرسال مصفوفة التحقق الكاملة، تعرض الأداة المساعدة بصورة حتمية نص إصدار GitHub الخاص بالوسم الدقيق، وترفض غياب عنوان الإصدار، أو نصًا يتجاوز الحد ولا يمكنه استخدام الصيغة الموجزة القياسية، أو مصدرًا لقاعدة/هدف سجل المساهمات لا يمكن الوصول إليه من الوسم. كما تتحقق من أي بيانات وصفية صريحة لاستبعاد خط أساس الإصدارات المشحونة بمقارنتها بسجلات الوسوم التراكمية المشار إليها. ثم تشغّل فحوص الإصدار المولّدة محليًا، وترسل أو تتحقق من أدلة التحقق الكامل من الإصدار والفحص التمهيدي لـ npm، وتشغّل دليل التثبيت الجديد/التحديث في Parallels مقابل حزمة tar الدقيقة المُعدّة بالإضافة إلى دليل حزمة Telegram، وتسجل خطط npm وClawHub الخاصة بالـ plugins، ولا تطبع أمر OpenClaw Release Publish الدقيق إلا بعد أن تصبح حزمة الأدلة سليمة.

    يرسل OpenClaw Release Publish حزم plugins المحددة أو جميع الحزم القابلة للنشر إلى npm والمجموعة نفسها إلى ClawHub بالتوازي، ثم يروّج أثر الفحص التمهيدي المُعدّ لـ npm الخاص بـ OpenClaw باستخدام وسم التوزيع المطابق بعد نجاح نشر plugins إلى npm. يظل سحب الإصدار جذر المنتج/البيانات، بينما يُنفّذ التخطيط والتحقق النهائي من سحب مصدر سير العمل الموثوق به بدقة، حتى لا يتمكن التزام إصدار أقدم من استخدام أدوات إصدار قديمة بصمت. قبل بدء أي عملية نشر فرعية، يعرض نص إصدار GitHub الدقيق ويخزنه مؤقتًا. عندما يلائم القسم المطابق الكامل من CHANGELOG.md حد GitHub البالغ 125,000 محرف وسقف الأمان المطابق للعارض البالغ 125,000 بايت، تحتوي الصفحة على قسم ## YYYY.M.PATCH نفسه تمامًا، بما في ذلك عنوانه. عندما لا يلائم قسم المصدر، تحتفظ الصفحة بالملاحظات التحريرية المجمعة نفسها تمامًا وتستبدل سجل المساهمات المتضخم برابط ثابت إلى السجل الكامل في CHANGELOG.md المثبّت عند الوسم؛ ولا تُنشر أبدًا سجلات جزئية أو نقاط مقتطعة. يختار سير العمل النص الكامل أو الموجز قبل إضافة ### التحقق من الإصدار؛ وإذا كان ذيل الإثبات سيتجاوز الحد، فإنه يحتفظ بالنص القياسي ويعتمد بدلًا من ذلك على الدليل المرفق غير القابل للتغيير. تصبح الإصدارات المستقرة المنشورة إلى وسم npm ‏latest أحدث إصدار على GitHub، بينما تُنشأ إصدارات الصيانة المستقرة المحتفظ بها على وسم npm ‏beta مع latest=false في GitHub. يرفع سير العمل أيضًا أدلة تبعيات الفحص التمهيدي، وبيان التحقق الكامل، وأدلة التحقق من السجل بعد النشر إلى إصدار GitHub للاستجابة للحوادث بعد الإصدار. يطبع معرّفات التشغيلات الفرعية فورًا، ويوافق تلقائيًا على بوابات بيئة الإصدار التي يُسمح لرمز سير العمل بالموافقة عليها، ويلخّص المهام الفرعية الفاشلة مع أواخر السجلات، وينشئ صفحة مسودة إصدار GitHub مقدمًا ويروّج أصول Windows وAndroid بالتزامن مع نشر OpenClaw إلى npm، ويُنهي صفحة الإصدار وأدلة التبعيات بعد نجاح تلك المراحل، وينتظر ClawHub كلما كان OpenClaw يُنشر إلى npm، ثم يشغّل متحقق بيتا من main الموثوق به ويرفع أدلة ما بعد النشر لإصدار GitHub، وحزمة npm، وحزم plugins المحددة على npm، وحزم ClawHub المحددة، ومعرّفات تشغيلات سير العمل الفرعية، ومعرّف تشغيل NPM الاختياري الخاص بـ Telegram. يتطلب متحقق تمهيد ClawHub مسار سير العمل وSHA الدقيقين لـ main الموثوق به، ومحاولات تشغيل المنتج والتشغيل النهائي، وSHA الإصدار، ومجموعة الحزم المطلوبة، ورباعية أثر الحزمة غير القابلة للتغيير، وأثر القراءة الراجعة النهائية من السجل؛ ولا يُقبل تشغيل ناجح قديم يستند إلى مرجع إصدار.

    بعد ذلك، شغّل اختبار قبول الحزمة بعد النشر على الحزمة المنشورة openclaw@YYYY.M.PATCH-beta.N أو openclaw@beta. إذا احتاج إصدار تمهيدي مدفوع أو منشور إلى إصلاح، فأنشئ رقم الإصدار التمهيدي المطابق التالي؛ ولا تحذف الإصدار القديم أو تعيد كتابته أبدًا.

  10. بالنسبة إلى الإصدار المستقر، لا تتابع إلا بعد أن يمتلك إصدار بيتا المدقق أو مرشح الإصدار أدلة التحقق المطلوبة. يمر نشر npm المستقر أيضًا عبر OpenClaw Release Publish، مع إعادة استخدام أثر الفحص التمهيدي الناجح بواسطة preflight_run_id. يتطلب استعداد إصدار macOS المستقر أيضًا ملفات .zip و.dmg و.dSYM.zip المعبأة، وملف appcast.xml المحدّث على main؛ وينشر سير عمل نشر macOS ملف appcast الموقّع تلقائيًا إلى main العام بعد التحقق من أصول الإصدار، أو يفتح/يحدّث طلب سحب لملف appcast إذا منعت حماية الفرع الدفع المباشر. يتطلب استعداد Windows Hub المستقر وجود الأصول الموقّعة OpenClawCompanion-Setup-x64.exe وOpenClawCompanion-Setup-arm64.exe وOpenClawCompanion-SHA256SUMS.txt في إصدار OpenClaw على GitHub. مرّر وسم إصدار openclaw/openclaw-windows-node الموقّع والدقيق بصفته windows_node_tag وخريطة ملخصات المثبت التي وافق عليها المرشح بصفة windows_node_installer_digests؛ يحتفظ OpenClaw Release Publish بمسودة الإصدار، ويرسل Windows Node Release، ويتحقق من الأصول الثلاثة كلها قبل النشر.

  11. بعد النشر، شغّل متحقق ما بعد النشر لـ npm، واختبار Telegram الشامل الاختياري المستقل لحزمة npm المنشورة عندما تحتاج إلى إثبات القناة بعد النشر، وروّج وسم التوزيع عند الحاجة، وتحقق من صفحة إصدار GitHub المولّدة، ونفّذ خطوات إعلان الإصدار، ثم أكمل إغلاق main المستقر قبل اعتبار الإصدار المستقر مكتملًا.

إغلاق main المستقر

لا يكتمل النشر المستقر حتى يحمل main حالة الإصدار المشحون الفعلية.

  1. ابدأ من أحدث نسخة جديدة من main. دقّق release/YYYY.M.PATCH بالمقارنة معها، وانقل إلى الأمام الإصلاحات الحقيقية غير الموجودة في main. لا تدمج بصورة عمياء محولات التوافق أو الاختبار أو التحقق الخاصة بالإصدار فقط في main الأحدث.
  2. اضبط main على الإصدار المستقر المشحون، وليس على مسار إصدار تالٍ افتراضي. شغّل pnpm release:prep بعد تغيير إصدار الجذر، ثم شغّل pnpm deps:shrinkwrap:generate.
  3. اجعل قسم ## YYYY.M.PATCH في CHANGELOG.md على main مطابقًا تمامًا لفرع الإصدار الموسوم. ضمّن تحديث appcast.xml المستقر عندما يكون إصدار Mac قد نشره.
  4. لا تضف YYYY.M.PATCH+1، أو إصدار بيتا، أو قسم سجل تغييرات مستقبليًا فارغًا إلى main حتى يبدأ المشغّل مسار الإصدار ذاك صراحةً.
  5. شغّل pnpm release:generated:check وpnpm deps:shrinkwrap:check وOPENCLAW_TESTBOX=1 pnpm check:changed. ادفع التغييرات، ثم تحقق من أن origin/main يحتوي على الإصدار المشحون وسجل التغييرات قبل اعتبار الإصدار المستقر مكتملًا.
  6. أبقِ متغيرَي المستودع RELEASE_ROLLBACK_DRILL_ID وRELEASE_ROLLBACK_DRILL_DATE محدّثين بعد كل تدريب خاص على التراجع.

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

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

يمكن لوسم تصحيح احتياطي قديم إعادة استخدام أدلة الحزمة الأساسية فقط عندما يُحل وسم التصحيح إلى التزام المصدر نفسه الذي يُحل إليه الوسم المستقر الأساسي. يعيد إصدار Android الخاص به استخدام ملف APK المتحقق منه للوسم الأساسي، ويضيف معلومات المصدر الخاصة بوسم التصحيح. يجب أن ينشر التصحيح ذو المصدر المختلف أدلة الحزمة الخاصة به ويتحقق منها، وأن يستخدم قيمة versionCode أعلى لنظام Android.

الفحص التمهيدي للإصدار

  • شغّل pnpm check:test-types قبل الفحص التمهيدي للإصدار لضمان استمرار تغطية TypeScript الخاص بالاختبارات خارج بوابة pnpm check المحلية الأسرع.

  • شغّل pnpm check:architecture قبل الفحص التمهيدي للإصدار لضمان نجاح فحوصات دورات الاستيراد الأوسع وحدود البنية خارج البوابة المحلية الأسرع.

  • شغّل pnpm build && pnpm ui:build قبل pnpm release:check لكي تكون عناصر إصدار dist/* المتوقعة وحزمة واجهة التحكم موجودة لخطوة التحقق من الحزمة.

  • شغّل pnpm release:prep بعد رفع إصدار الجذر وقبل إنشاء الوسم. يشغّل هذا الأمر جميع مولّدات الإصدار الحتمية التي يشيع انحرافها بعد تغيير الإصدار أو الإعدادات أو API: إصدارات المكوّنات الإضافية، وملفات تقليص npm، وقائمة المكوّنات الإضافية، ومخطط الإعدادات الأساسي، وبيانات تعريف إعدادات القنوات المضمّنة، وخط أساس وثائق الإعدادات، وتصديرات SDK للمكوّنات الإضافية، وخط أساس API الخاص بـ SDK للمكوّنات الإضافية. يعيد pnpm release:check تشغيل وسائل الحماية هذه في وضع الفحص (بالإضافة إلى فحص ميزانية سطح SDK للمكوّنات الإضافية)، ويبلّغ عن كل حالات فشل انحراف المحتوى المولّد في مرور واحد قبل تشغيل فحوصات إصدار الحزم.

  • تحدّث مزامنة إصدارات المكوّنات الإضافية افتراضيًا حزمة وقت التشغيل @openclaw/ai القابلة للنشر، وإصدارات حزم المكوّنات الإضافية الرسمية، والحدود الدنيا الحالية لـ openclaw.compat.pluginApi إلى إصدار OpenClaw. تعامل مع هذا الحقل بوصفه الحد الأدنى لـ API الخاص بـ SDK/وقت تشغيل المكوّنات الإضافية، وليس مجرد نسخة من إصدار الحزمة: بالنسبة إلى إصدارات المكوّنات الإضافية فقط التي يُراد لها عمدًا أن تظل متوافقة مع مضيفات OpenClaw الأقدم، أبقِ الحد الأدنى عند أقدم API مضيف مدعوم ووثّق هذا الاختيار في إثبات إصدار المكوّن الإضافي.

  • شغّل سير العمل اليدوي Full Release Validation قبل الموافقة على الإصدار لبدء جميع بيئات اختبار ما قبل الإصدار من نقطة دخول واحدة. يقبل فرعًا أو وسمًا أو معرّف SHA كاملًا لالتزام، ويطلق CI يدويًا، كما يطلق OpenClaw Release Checks لفحص التثبيت السريع، وقبول الحزمة، وفحوصات الحزمة عبر أنظمة التشغيل، وتكافؤ QA Lab، ومسارات Matrix وTelegram. تتضمن عمليات التشغيل المستقرة والكاملة دائمًا اختبارات live/E2E شاملة واختبار تحمّل لمسار إصدار Docker؛ ويُحتفظ بـ run_release_soak=true لإجراء اختبار تحمّل صريح لإصدار بيتا. يوفّر قبول الحزمة اختبار Telegram E2E القياسي للحزمة أثناء التحقق من الإصدار المرشح، ما يتجنب تشغيل مستطلع مباشر ثانٍ بالتزامن.

    قدّم release_package_spec بعد نشر إصدار بيتا لإعادة استخدام حزمة npm المنشورة عبر فحوصات الإصدار وقبول الحزمة واختبار Telegram E2E للحزمة، من دون إعادة بناء ملف tarball الخاص بالإصدار. قدّم npm_telegram_package_spec فقط عندما ينبغي أن يستخدم Telegram حزمة منشورة مختلفة عن بقية عملية التحقق من الإصدار. قدّم package_acceptance_package_spec عندما ينبغي أن يستخدم قبول الحزمة حزمة منشورة مختلفة عن مواصفات حزمة الإصدار. قدّم evidence_package_spec عندما ينبغي أن يثبت تقرير أدلة الإصدار أن التحقق يطابق حزمة npm منشورة من دون فرض تشغيل Telegram E2E.

    bash
    gh workflow run full-release-validation.yml --ref main -f ref=release/YYYY.M.PATCH

  • شغّل سير العمل اليدوي Package Acceptance عندما تريد إثباتًا عبر مسار جانبي لحزمة مرشحة بينما يستمر العمل على الإصدار. استخدم source=npm مع openclaw@beta أو openclaw@latest أو إصدار دقيق؛ واستخدم source=ref لحزم فرع أو وسم أو SHA موثوق به في package_ref باستخدام بيئة الاختبار الحالية في workflow_ref؛ واستخدم source=url لملف tarball عام عبر HTTPS مع قيمة SHA-256 مطلوبة وسياسة صارمة لعناوين URL العامة؛ واستخدم source=trusted-url لسياسة مصدر موثوق مسمّاة باستخدام trusted_source_id وقيمة SHA-256 المطلوبين؛ أو استخدم source=artifact لملف tarball رفعته عملية تشغيل أخرى في GitHub Actions.

    يحوّل سير العمل الحزمة المرشحة إلى package-under-test، ويعيد استخدام مجدول إصدار Docker E2E مع ملف tarball هذا، ويمكنه تشغيل اختبارات ضمان الجودة لـ Telegram باستخدام ملف tarball نفسه مع telegram_mode=mock-openai أو telegram_mode=live-frontier. عندما تتضمن مسارات Docker المحددة published-upgrade-survivor، يكون عنصر الحزمة هو الإصدار المرشح، ويحدد published_upgrade_survivor_baseline خط الأساس المنشور. يستخدم update-restart-auth الحزمة المرشحة بوصفها كلًا من CLI المثبّت والحزمة قيد الاختبار، بحيث يختبر مسار إعادة التشغيل المُدار لأمر التحديث في الإصدار المرشح.

    مثال:

    bash
    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: مسارات الحزمة والتحديث وإعادة التشغيل والمكوّنات الإضافية المعتمدة على عناصر الحزمة، من دون OpenWebUI أو ClawHub المباشر
    • product: ملف تعريف الحزمة بالإضافة إلى قنوات MCP، وتنظيف Cron والوكلاء الفرعيين، وبحث الويب عبر OpenAI، وOpenWebUI
    • full: أجزاء مسار إصدار Docker مع OpenWebUI
    • custom: تحديد دقيق لـ docker_lanes لإعادة تشغيل مركّزة

  • شغّل سير العمل اليدوي CI مباشرةً عندما لا تحتاج إلا إلى تغطية CI عادية وحتمية للإصدار المرشح. تتجاوز عمليات الإطلاق اليدوية لـ CI تحديد النطاق وفق التغييرات، وتفرض تشغيل تقسيمات Linux Node، وتقسيمات المكوّنات الإضافية المضمّنة، وتقسيمات عقود المكوّنات الإضافية والقنوات، وتوافق Node 22، وcheck-*، وcheck-additional-*، وفحوصات العناصر المبنية السريعة، وفحوصات الوثائق، وSkills الخاصة بـ Python، وWindows، وmacOS، ومسارات التدويل لواجهة التحكم. تشغّل عمليات CI اليدوية المستقلة Android فقط عند إطلاقها باستخدام include_android=true؛ ويمرّر Full Release Validation هذا الإدخال إلى عملية CI التابعة له.

    bash
    gh workflow run ci.yml --ref release/YYYY.M.PATCH -f include_android=true

  • شغّل pnpm qa:otel:smoke عند التحقق من بيانات القياس عن بُعد للإصدار. يختبر QA Lab عبر مستقبِل OTLP/HTTP محلي، ويتحقق من تصدير الآثار والمقاييس والسجلات، ومن تقييد سمات الآثار وتنقيح المحتوى والمعرّفات، من دون الحاجة إلى Opik أو Langfuse أو أي مجمّع خارجي آخر.

  • شغّل pnpm qa:otel:collector-smoke عند التحقق من التوافق مع المجمّع. يوجّه تصدير OTLP نفسه من QA Lab عبر حاوية Docker حقيقية لـ OpenTelemetry Collector قبل تنفيذ تحققات المستقبِل المحلي.

  • شغّل pnpm qa:prometheus:smoke عند التحقق من جمع بيانات Prometheus المحمي. يختبر QA Lab، ويرفض عمليات الجمع غير المصادق عليها، ويتحقق من أن مجموعات المقاييس الحرجة للإصدار تظل خالية من محتوى المطالبات والمعرّفات الخام ورموز المصادقة والمسارات المحلية.

  • شغّل pnpm qa:observability:smoke لتشغيل مساري الفحص السريع لـ OpenTelemetry وPrometheus في نسخة الشيفرة المصدرية تباعًا.

  • شغّل pnpm release:check قبل كل إصدار ذي وسم.

  • يولّد الفحص التمهيدي لـ OpenClaw NPM Release أدلة إصدار التبعيات قبل أن يحزم ملف tarball الخاص بـ npm. تُعد بوابة الثغرات الأمنية في تنبيهات npm حاجبة للإصدار. أما تقارير مخاطر بيان التبعيات المتعدية، وملكية التبعيات وسطح تثبيتها، وتغييرات التبعيات، فهي أدلة للإصدار فقط. يقارن تقرير تغييرات التبعيات الإصدار المرشح بآخر وسم إصدار يمكن الوصول إليه. يرفع الفحص التمهيدي أدلة التبعيات باسم openclaw-release-dependency-evidence-<tag>، كما يضمّنها ضمن dependency-evidence/ داخل عنصر الفحص التمهيدي المُعدّ لـ npm. يعيد مسار النشر الفعلي استخدام عنصر الفحص التمهيدي هذا، ثم يرفق الأدلة نفسها بإصدار GitHub باسم openclaw-<version>-dependency-evidence.zip.

  • شغّل OpenClaw Release Publish لتنفيذ تسلسل النشر الذي يُجري تغييرات بعد وجود الوسم. أطلق عمليات نشر بيتا والإصدارات المستقرة العادية من main الموثوق به؛ إذ يظل وسم الإصدار يحدد الالتزام المستهدف بدقة، ويمكن أن يشير إلى release/YYYY.M.PATCH. تظل عمليات نشر Tideclaw alpha على فرع alpha المطابق لها. مرّر preflight_run_id الناجح الخاص بـ npm لـ OpenClaw، وfull_release_validation_run_id الناجح، والقيمة الدقيقة لـ full_release_validation_run_attempt، وأبقِ نطاق نشر المكوّنات الإضافية الافتراضي all-publishable ما لم تكن تُجري عمدًا إصلاحًا مركّزًا. ينفّذ سير العمل نشر المكوّنات الإضافية إلى npm، ثم نشرها إلى ClawHub، ثم نشر OpenClaw إلى npm بشكل تسلسلي، كي لا تُنشر الحزمة الأساسية قبل مكوّناتها الإضافية المفصولة عنها؛ ويجري ترويج Windows وAndroid بالتزامن مع نشر الحزمة الأساسية إلى npm وبالاستناد إلى صفحة مسودة الإصدار. يمكن استئناف عمليات إعادة النشر: فإذا كان إصدار الحزمة الأساسية منشورًا بالفعل على npm، يتجاوز سير العمل إطلاق نشر الحزمة الأساسية بعد إثبات أن ملف tarball في السجل يطابق عنصر الفحص التمهيدي الخاص بالوسم، كما يُتجاوز ترويج Windows وAndroid عندما يحتوي الإصدار بالفعل على عقد عناصر الحزمة المتحقق منه، بحيث تعيد المحاولة تنفيذ المراحل الفاشلة فقط. تتطلب إصلاحات المكوّنات الإضافية المركّزة فقط تعيين plugin_publish_scope=selected وقائمة غير فارغة من المكوّنات الإضافية. وتتطلب عمليات all-publishable الخاصة بالمكوّنات الإضافية فقط أدلة كاملة وغير قابلة للتغيير من الفحص التمهيدي وFull Release Validation؛ وتُرفض الأدلة الجزئية.

  • يتطلب OpenClaw Release Publish المستقر قيمة دقيقة لـ windows_node_tag بعد وجود إصدار مطابق وغير تمهيدي من openclaw/openclaw-windows-node، بالإضافة إلى خريطة windows_node_installer_digests المعتمدة للإصدار المرشح. قبل إطلاق أي عملية نشر تابعة، يتحقق من أن إصدار المصدر منشور وغير تمهيدي، ويحتوي على مثبّتات x64/ARM64 المطلوبة، ولا يزال يطابق الخريطة المعتمدة. ثم يطلق Windows Node Release بينما لا يزال إصدار OpenClaw مسودة، مع تمرير خريطة بصمات المثبّتات المثبّتة من دون تغيير. ينزّل سير العمل التابع مثبّتات Windows Hub الموقّعة من ذلك الوسم الدقيق، ويطابقها مع البصمات المثبّتة، ويتحقق على مشغّل Windows من أن توقيعات Authenticode الخاصة بها تستخدم جهة التوقيع المتوقعة OpenClaw Foundation، وينشئ بيان SHA-256، ويرفع المثبّتات والبيان إلى إصدار OpenClaw القياسي على GitHub، ثم يعيد تنزيل العناصر المروّجة ويتحقق من عضويتها في البيان ومن قيم التجزئة الخاصة بها. يتحقق سير العمل الأب من عقد عناصر x64 وARM64 وقيمة التحقق الحالية قبل النشر. ترفض الاستعادة المباشرة أسماء عناصر OpenClawCompanion-* غير المتوقعة قبل استبدال عناصر العقد المتوقعة ببايتات المصدر المثبّتة.

    لا تطلق Windows Node Release يدويًا إلا للاستعادة، ومرّر دائمًا وسمًا دقيقًا، وليس latest، بالإضافة إلى خريطة JSON الصريحة expected_installer_digests من إصدار المصدر المعتمد. ينبغي أن تستهدف روابط التنزيل على الموقع عناوين URL الدقيقة لعناصر إصدار OpenClaw المستقر الحالي، أو releases/latest/download/... فقط بعد التحقق من أن إعادة توجيه أحدث إصدار في GitHub تشير إلى الإصدار نفسه؛ ولا تضع رابطًا يقتصر على صفحة إصدار المستودع المصاحب.

  • تُشغَّل فحوصات الإصدار الآن ضمن سير عمل يدوي منفصل: OpenClaw Release Checks. ويشغّل أيضًا مسار تكافؤ المحاكاة في مختبر ضمان الجودة، بالإضافة إلى ملف تعريف Matrix الحي السريع ومسار ضمان جودة Telegram قبل الموافقة على الإصدار. تستخدم المسارات الحية بيئة qa-live-shared؛ ويستخدم Telegram أيضًا تأجيرات بيانات اعتماد Convex للتكامل المستمر. شغّل سير العمل اليدوي QA-Lab - All Lanes مع matrix_profile=all وmatrix_shards=true عندما تريد جردًا كاملًا ومتوازيًا للنقل والوسائط والتشفير من طرف إلى طرف في Matrix.

  • يُعد التحقق من تثبيت بيئة التشغيل وترقيتها عبر أنظمة التشغيل جزءًا من OpenClaw Release Checks وFull Release Validation العامَّين، اللذين يستدعيان سير العمل القابل لإعادة الاستخدام .github/workflows/openclaw-cross-os-release-checks-reusable.yml مباشرةً. هذا الفصل مقصود: إبقاء مسار إصدار npm الفعلي قصيرًا وحتميًا ومركّزًا على المصنوعات، بينما تبقى الفحوصات الحية الأبطأ في مسارها الخاص كي لا تؤخر النشر أو تمنعه.

  • يجب تشغيل فحوصات الإصدار التي تتضمن أسرارًا عبر Full Release Validation أو من مرجع سير العمل main/الإصدار، لكي يظل منطق سير العمل والأسرار خاضعين للتحكم.

  • يقبل OpenClaw Release Checks فرعًا أو وسمًا أو SHA كاملًا للالتزام، ما دام الالتزام المحسوم قابلًا للوصول من فرع OpenClaw أو وسم إصدار.

  • يقبل الفحص التمهيدي المخصص للتحقق فقط في OpenClaw NPM Release أيضًا SHA الكامل الحالي، المؤلف من 40 محرفًا، لالتزام فرع سير العمل دون اشتراط وسم مدفوع. يقتصر مسار SHA هذا على التحقق، ولا يمكن ترقيته إلى نشر فعلي. في وضع SHA، ينشئ سير العمل v<package.json version> فقط لفحص بيانات الحزمة الوصفية؛ أما النشر الفعلي فما يزال يتطلب وسم إصدار حقيقيًا.

  • يحافظ كلا سيري العمل على مسار النشر والترقية الفعلي على مشغّلات تستضيفها GitHub، بينما يمكن لمسار التحقق غير المعدِّل استخدام مشغّلات 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.PATCH-beta.N pnpm release:fast-pretag-check. يشغّل المساعد حواجز الإصدار السريعة، وفحوصات إصدار إضافات npm/ClawHub، والبناء، وبناء واجهة المستخدم، وrelease:openclaw:npm:check بالترتيب الذي يكتشف الأخطاء الشائعة المانعة للموافقة قبل بدء سير عمل النشر في GitHub.

  • شغّل RELEASE_TAG=vYYYY.M.PATCH node --import tsx scripts/openclaw-npm-release-check.ts (أو وسم ما قبل الإصدار/التصحيح المطابق) قبل الموافقة.

  • بعد النشر إلى npm، شغّل node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.PATCH (أو إصدار بيتا/التصحيح المطابق) للتحقق من مسار تثبيت السجل المنشور ضمن بادئة مؤقتة جديدة.

  • بعد نشر إصدار بيتا، شغّل OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC=openclaw@YYYY.M.PATCH-beta.N OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=ci pnpm test:docker:npm-telegram-live للتحقق من الإعداد الأولي للحزمة المثبتة، وإعداد Telegram، والاختبار الحقيقي من طرف إلى طرف في Telegram مقابل حزمة npm المنشورة باستخدام مجموعة بيانات اعتماد Telegram المؤجّرة والمشتركة. يمكن لعمليات المشرف المحلية المنفردة حذف متغيرات Convex وتمرير بيانات اعتماد البيئة الثلاث OPENCLAW_QA_TELEGRAM_* مباشرةً.

  • لتشغيل اختبار بيتا الكامل بعد النشر من جهاز مشرف، استخدم pnpm release:beta-smoke -- --beta betaN. يشغّل المساعد التحقق من تحديث npm والهدف الجديد في Parallels، ويطلق NPM Telegram Beta E2E، ويستطلع تشغيل سير العمل المحدد، وينزّل المصنوعة، ويطبع تقرير Telegram.

  • يمكن للمشرفين تشغيل الفحص نفسه بعد النشر من GitHub Actions عبر سير العمل اليدوي NPM Telegram Beta E2E. وهو يدوي فقط عن قصد ولا يُشغَّل مع كل دمج.

  • تستخدم أتمتة الإصدار الخاصة بالمشرفين نهج الفحص التمهيدي ثم الترقية:

    • يجب أن يجتاز النشر الفعلي إلى npm معرّف تشغيل فحص تمهيدي ناجح لـ npm في preflight_run_id.
    • تستخدم أتمتة نشر إصدارات بيتا العادية والمستقرة وفحصها التمهيدي main الموثوق مقابل وسم الهدف المحدد. ويستخدم نشر Tideclaw alpha وفحصه التمهيدي فرع alpha المطابق.
    • تستهدف إصدارات npm المستقرة beta افتراضيًا؛ ويمكن لنشر npm المستقر استهداف latest صراحةً عبر مُدخل سير العمل.
    • يوجد تعديل وسم توزيع npm المعتمد على الرمز المميز في openclaw/releases/.github/workflows/openclaw-npm-dist-tags.yml لأن npm dist-tag add ما يزال يحتاج إلى NPM_TOKEN، بينما يحافظ مستودع المصدر على نشر يعتمد على OIDC فقط.
    • يقتصر macOS Release العام على التحقق؛ وعندما لا يوجد الوسم إلا على فرع إصدار لكن يُشغَّل سير العمل من main، اضبط public_release_branch=release/YYYY.M.PATCH.
    • يجب أن يجتاز النشر الفعلي لنظام macOS معرّف تشغيل فحص تمهيدي ناجحًا لنظام macOS في preflight_run_id ومعرّف تشغيل تحقق ناجحًا في validate_run_id.
    • تعمل مسارات النشر الفعلي على ترقية المصنوعات المحضّرة بدلًا من إعادة بنائها.

  • بالنسبة إلى إصدارات التصحيح المستقرة مثل YYYY.M.PATCH-N، يفحص مدقق ما بعد النشر أيضًا مسار الترقية نفسه ذي البادئة المؤقتة من YYYY.M.PATCH إلى YYYY.M.PATCH-N، بحيث لا تتمكن تصحيحات الإصدار من إبقاء عمليات التثبيت العامة الأقدم بصمت على حمولة الإصدار المستقر الأساسي.

  • يفشل الفحص التمهيدي لإصدار npm بوضع الإغلاق الآمن ما لم تتضمن الحزمة المضغوطة كلًا من dist/control-ui/index.html وحمولة غير فارغة في dist/control-ui/assets/، كي لا نشحن لوحة معلومات فارغة للمتصفح مرة أخرى.

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

  • يفرض pnpm test:install:smoke أيضًا ميزانية unpackedSize لحزمة npm على حزمة التحديث المرشحة، بحيث يكتشف الاختبار الشامل للمثبّت تضخم الحزمة غير المقصود قبل مسار نشر الإصدار.

  • إذا طال عمل الإصدار تخطيط التكامل المستمر أو بيانات توقيت الإضافات أو مصفوفات اختبار الإضافات، فأعِد إنشاء مخرجات مصفوفة plugin-prerelease-extension-shard المملوكة للمخطط من .github/workflows/plugin-prerelease.yml وراجعها قبل الموافقة، كي لا تصف ملاحظات الإصدار تخطيطًا قديمًا للتكامل المستمر.

  • يشمل الاستعداد لإصدار macOS المستقر أيضًا أسطح برنامج التحديث: يجب أن يحتوي إصدار GitHub في النهاية على ملفات .zip و.dmg و.dSYM.zip المجمّعة؛ ويجب أن يشير appcast.xml على main إلى ملف zip المستقر الجديد بعد النشر (يلتزمه سير عمل نشر macOS تلقائيًا، أو يفتح طلب سحب لملف appcast عندما يُمنع الدفع المباشر)؛ ويجب أن يحتفظ التطبيق المجمّع بمعرّف حزمة غير مخصص للتنقيح، وعنوان URL غير فارغ لخلاصة Sparkle، وقيمة CFBundleVersion لا تقل عن الحد الأدنى الأساسي المعتمد لبناء Sparkle لإصدار البرنامج ذاك.

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

يمثّل Full Release Validation الطريقة التي يبدأ بها المشغّلون جميع اختبارات ما قبل الإصدار من نقطة دخول واحدة. للحصول على إثبات لالتزام مثبّت على فرع سريع التغير، استخدم المساعد كي يعمل كل سير عمل فرعي من فرع مؤقت مثبت عند SHA واحد موثوق لسير عمل main، بينما يظل الالتزام المطلوب هو المرشح قيد الاختبار:

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

يجلب المساعد origin/main الحالي، ويدفع release-ci/<workflow-sha>-... عند التزام سير العمل الموثوق ذاك، ويشغّل Full Release Validation من الفرع المؤقت مع ref=<target-sha>، ويعيد استخدام دليل صارم للهدف المحدد عند توفره، ويتحقق من أن كل headSha لسير عمل فرعي يطابق SHA سير العمل الأب المثبّت، ثم يحذف الفرع المؤقت. مرّر -f reuse_evidence=false لفرض تشغيل جديد أو --workflow-sha <trusted-main-sha> لتثبيت التزام أقدم ما يزال قابلًا للوصول من origin/main الحالي. لا يكتب سير العمل نفسه مراجع المستودع مطلقًا. يتيح ذلك بقاء أدوات الإصدار الخاصة بـmain متاحة دون إضافة التزامات أدوات إلى المرشح، ويتجنب إثبات تشغيل فرعي أحدث لـmain عن طريق الخطأ.

للتحقق من فرع إصدار أو وسم، شغّله من مرجع سير العمل الموثوق main ومرّر فرع الإصدار أو الوسم بصفته ref:

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

يحلّ سير العمل مرجع الهدف، ويشغّل CI اليدوي مع target_ref=<release-ref>، ثم يشغّل OpenClaw Release Checks. يوزّع OpenClaw Release Checks اختبار التثبيت السريع، وفحوصات الإصدار عبر أنظمة التشغيل، وتغطية مسار الإصدار الحية/الشاملة في Docker عند تمكين اختبار التحمل، وقبول الحزمة مع الاختبار الشامل الأساسي لحزمة Telegram، وتكافؤ مختبر ضمان الجودة، وMatrix الحي، وTelegram الحي. لا يُقبل التشغيل الكامل/الشامل إلا عندما يُظهر ملخص Full Release Validation نجاح normal_ci وplugin_prerelease وrelease_checks، ما لم يتجاوز تشغيل مركّز معادٌ عمدًا المسار الفرعي المنفصل Plugin Prerelease. استخدم المسار الفرعي المستقل npm-telegram فقط لإعادة تشغيل مركّزة لحزمة منشورة باستخدام release_package_spec أو npm_telegram_package_spec. يتضمن ملخص المدقق النهائي جداول الوظائف الأبطأ لكل تشغيل فرعي، بحيث يستطيع مدير الإصدار رؤية المسار الحرج الحالي دون تنزيل السجلات.

يقتصر المسار الفرعي لأداء المنتج على المصنوعات في مسار الإصدار هذا. يشغّله سير العمل الجامع مع publish_reports=false، ويُرفض التحقق ما لم يثبت حاجز المصنوعات فقط أن ناشر تقرير Clawgrit ظل متجاوزًا.

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

تُشغَّل مسارات العمل الفرعية من المرجع الموثوق الذي يشغّل Full Release Validation، وهو عادةً --ref main، حتى عندما يشير ref الهدف إلى فرع إصدار أو وسم أقدم. يجب أن يستخدم كل تشغيل فرعي SHA المحدد نفسه لسير العمل الأب؛ وإذا تقدم main قبل اكتمال تشغيل سير عمل فرعي، يفشل سير العمل الجامع بوضع الإغلاق الآمن. لا يوجد مُدخل منفصل لمرجع سير عمل Full Release Validation؛ اختر حاضنة التشغيل الموثوقة باختيار مرجع تشغيل سير العمل. لا تستخدم --ref main -f ref=<sha> لإثبات التزام محدد على main متحرك؛ إذ لا يمكن استخدام قيم SHA الخام للالتزامات كمراجع لتشغيل سير العمل، لذا استخدم pnpm ci:full-release --sha <target-sha> لإنشاء فرع مؤقت عند origin/main الموثوق مع إبقاء SHA الهدف مُدخلًا للمرشح.

استخدم release_profile لتحديد اتساع التغطية الحية/تغطية المزوّد:

  • minimum: أسرع مسار حي ومسار Docker حرجين للإصدار في OpenAI/النواة
  • stable: الحد الأدنى بالإضافة إلى تغطية مستقرة للمزوّد/الواجهة الخلفية من أجل الموافقة على الإصدار
  • full: الملف المستقر بالإضافة إلى تغطية استشارية واسعة للمزوّدين/الوسائط

يشغّل التحقق المستقر والكامل دائمًا الفحص الشامل الحي/من طرف إلى طرف، ومسار إصدار Docker، والمسح المحدود المنشور للترقيات الباقية قبل الترقية. استخدم run_release_soak=true لطلب المسح نفسه لإصدار بيتا. يغطي ذلك المسح أحدث أربع حزم مستقرة، بالإضافة إلى خطي الأساس المثبّتين 2026.4.23 و2026.5.2، وكذلك تغطية 2026.4.15 الأقدم، مع إزالة خطوط الأساس المكررة وتوزيع كل خط أساس على وظيفة مشغّل Docker مستقلة.

يستخدم OpenClaw Release Checks مرجع سير العمل الموثوق لحل مرجع الهدف مرة واحدة بوصفه release-package-under-test، ثم يعيد استخدام تلك المصنوعة في فحوصات الأنظمة المتعددة، وقبول الحزمة، وفحوصات Docker لمسار الإصدار عند تشغيل اختبار التحمل. يحافظ ذلك على استخدام جميع صناديق الحزم للبايتات نفسها ويتجنب تكرار بناء الحزمة. بعد توفر إصدار بيتا على npm، اضبط release_package_spec=openclaw@YYYY.M.PATCH-beta.N لكي تنزّل فحوصات الإصدار الحزمة المشحونة مرة واحدة، وتستخرج SHA مصدر بنائها من dist/build-info.json، وتعيد استخدام تلك المصنوعة لمسارات الأنظمة المتعددة، وقبول الحزمة، وDocker لمسار الإصدار، وحزمة Telegram.

يستخدم اختبار تثبيت OpenAI السريع عبر أنظمة التشغيل OPENCLAW_CROSS_OS_OPENAI_MODEL عند ضبط متغير المستودع/المؤسسة، وإلا فيستخدم openai/gpt-5.6-luna، لأن هذا المسار يثبت تثبيت الحزمة، والإعداد الأولي، وتشغيل Gateway، ودورة واحدة حية للوكيل، بدلًا من قياس أداء النموذج الأعلى قدرة. وتظل مصفوفة المزوّدين الحية الأوسع هي موضع التغطية الخاصة بالنماذج.

استخدم هذه المتغيرات بحسب مرحلة الإصدار:

bash
# التحقق من فرع مرشح إصدار غير منشور.gh workflow run full-release-validation.yml \  --ref main \  -f ref=release/YYYY.M.PATCH \  -f provider=openai \  -f mode=both \  -f release_profile=stable # التحقق من التزام مدفوع محدد بدقة.gh workflow run full-release-validation.yml \  --ref main \  -f ref=<40-char-sha> \  -f provider=openai \  -f mode=both # بعد نشر إصدار تجريبي، أضف اختبار Telegram الشامل من البداية إلى النهاية للحزمة المنشورة.gh workflow run full-release-validation.yml \  --ref main \  -f ref=release/YYYY.M.PATCH \  -f provider=openai \  -f mode=both \  -f release_profile=full \  -f release_package_spec=openclaw@YYYY.M.PATCH-beta.N \  -f evidence_package_spec=openclaw@YYYY.M.PATCH-beta.N \  -f npm_telegram_provider_mode=mock-openai

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

يمكن لـ rerun_group=all إعادة استخدام تشغيل مظلة أخضر سابق فقط عندما يكون قد تحقق من SHA الهدف نفسه تمامًا، وملف تعريف الإصدار نفسه، وإعداد الاختبار المطوّل الفعلي نفسه، ومدخلات التحقق نفسها. هذا استرداد محدود لإعادة تشغيل المرشح نفسه، وليس إعادة استخدام للأدلة عبر قيم SHA مختلفة. بالنسبة إلى مرشح متغير، بما في ذلك التزام يقتصر على سجل التغييرات أو الإصدار، أعد تشغيل كل بوابة حزمة أو عنصر أو تثبيت أو Docker أو موفر تأثرت بالمسارات المتغيرة أو تجزئات العناصر. تحل تشغيلات المظلة الأحدث للمرجع release/* نفسه ومجموعة إعادة التشغيل نفسها تلقائيًا محل التشغيلات الجارية. مرّر reuse_evidence=false لفرض تشغيل كامل جديد.

للاسترداد المحدود، مرّر rerun_group إلى المظلة. تمثل all تشغيل مرشح الإصدار الحقيقي، وتشغّل ci عنصر CI الفرعي العادي فقط، وتشغّل plugin-prerelease عنصر Plugin الخاص بالإصدار فقط، وتشغّل release-checks جميع بيئات الإصدار، ومجموعات الإصدار الأضيق هي install-smoke وcross-os وlive-e2e وpackage وqa وqa-parity وqa-live وnpm-telegram. تتطلب عمليات إعادة التشغيل المحددة النطاق لـ npm-telegram القيمة release_package_spec أو npm_telegram_package_spec؛ وتستخدم التشغيلات الكاملة/الشاملة اختبار Telegram الشامل من البداية إلى النهاية الأساسي للحزمة داخل قبول الحزمة. يمكن لعمليات إعادة التشغيل المحددة النطاق عبر أنظمة التشغيل إضافة cross_os_suite_filter=windows/packaged-upgrade أو مرشح آخر لنظام التشغيل/مجموعة الاختبارات. تمنع إخفاقات فحوص إصدار ضمان الجودة التحقق العادي من الإصدار، بما في ذلك انحراف الأدوات الديناميكية المطلوب في OpenClaw ضمن المستوى القياسي. ومع ذلك، قد تظل تشغيلات Tideclaw alpha تتعامل مع مسارات فحوص الإصدار غير المتعلقة بسلامة الحزمة على أنها استشارية. مع release_profile=beta، تكون مجموعات موفر الإنتاج في Run repo/live E2E validation استشارية (تحذيرات وليست عوائق)؛ وتبقيها ملفات التعريف المستقرة والكاملة مانعة. عندما يطلب live_suite_filter صراحةً مسار ضمان جودة مباشرًا خاضعًا للبوابة مثل Discord أو WhatsApp أو Slack، يجب تمكين متغير المستودع المطابق OPENCLAW_RELEASE_QA_*_LIVE_CI_ENABLED؛ وإلا يفشل التقاط المدخلات بدلًا من تخطي المسار بصمت.

Vitest

بيئة Vitest هي سير عمل العنصر الفرعي اليدوي CI. يتجاوز CI اليدوي عمدًا تحديد النطاق بناءً على التغييرات ويفرض مخطط الاختبارات العادي لمرشح الإصدار: أجزاء Linux Node، وأجزاء Plugin المضمنة، وأجزاء عقود Plugin والقنوات، والتوافق مع Node 22، وcheck-*، وcheck-additional-*، وفحوص سلامة العناصر المبنية، وفحوص المستندات، وSkills الخاصة بـ Python، وWindows، وmacOS، وتدويل واجهة التحكم. يُضمَّن Android عندما يشغّل Full Release Validation البيئة لأن المظلة تمرّر include_android=true؛ ويتطلب CI اليدوي المستقل include_android=true لتغطية Android.

استخدم هذه البيئة للإجابة عن السؤال: «هل اجتازت شجرة المصدر مجموعة الاختبارات العادية الكاملة؟». وهي لا تماثل التحقق من المنتج عبر مسار الإصدار. الأدلة الواجب الاحتفاظ بها:

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

شغّل CI اليدوي مباشرةً فقط عندما يحتاج الإصدار إلى CI عادي حتمي دون بيئات Docker أو مختبر ضمان الجودة أو الإنتاج أو الأنظمة المتعددة أو الحزم. استخدم الأمر الأول لـ CI المباشر من دون Android. أضف include_android=true عندما يجب أن يغطي CI المباشر لمرشح الإصدار Android:

bash
gh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.PATCHgh workflow run ci.yml --ref main -f target_ref=release/YYYY.M.PATCH -f include_android=true

Docker

توجد بيئة Docker في OpenClaw Release Checks من خلال openclaw-live-and-e2e-checks-reusable.yml، بالإضافة إلى سير عمل install-smoke في وضع الإصدار. وهي تتحقق من مرشح الإصدار عبر بيئات Docker المحزّمة بدلًا من الاكتفاء باختبارات مستوى المصدر.

تشمل تغطية Docker للإصدار:

  • فحص سلامة كامل للتثبيت مع تمكين فحص سلامة التثبيت العام البطيء لـ Bun
  • إعداد/إعادة استخدام صورة فحص سلامة Dockerfile الجذري حسب SHA الهدف، مع تشغيل مهام فحص سلامة QR والجذر/Gateway والمثبّت/Bun كأجزاء مستقلة من install-smoke
  • مسارات شاملة من البداية إلى النهاية للمستودع
  • أجزاء 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، وopenwebui
  • تغطية OpenWebUI على مشغّل مخصص بقرص كبير عند طلبها
  • مسارات تثبيت/إلغاء تثبيت Plugin المضمنة المقسّمة من bundled-plugin-install-uninstall-0 إلى bundled-plugin-install-uninstall-23
  • مجموعات موفري الإنتاج/الاختبارات الشاملة من البداية إلى النهاية وتغطية نماذج Docker المباشرة عندما تتضمن فحوص الإصدار مجموعات مباشرة

استخدم عناصر Docker قبل إعادة التشغيل. يرفع مجدول مسار الإصدار .artifacts/docker-tests/ متضمنًا سجلات المسارات وsummary.json وfailures.json وتوقيتات المراحل وJSON لخطة المجدول وأوامر إعادة التشغيل. للاسترداد المحدد النطاق، استخدم docker_lanes=<lane[,lane]> في سير عمل الإنتاج/الاختبارات الشاملة من البداية إلى النهاية القابل لإعادة الاستخدام بدلًا من إعادة تشغيل جميع أجزاء الإصدار. تتضمن أوامر إعادة التشغيل المولّدة package_artifact_run_id السابق ومدخلات صور Docker المُعدّة عند توفرها، بحيث يمكن لمسار فاشل إعادة استخدام ملف tarball وصور GHCR نفسيهما.

مختبر ضمان الجودة

بيئة مختبر ضمان الجودة جزء أيضًا من OpenClaw Release Checks. وهي بوابة الإصدار للسلوك الوكيلي وعلى مستوى القنوات، ومنفصلة عن Vitest وآليات حزمة Docker.

تشمل تغطية مختبر ضمان الجودة للإصدار:

  • مسار تكافؤ وهمي يقارن مسار مرشح OpenAI بخط الأساس anthropic/claude-opus-4-8 باستخدام حزمة التكافؤ الوكيلية
  • ملف تعريف سريع لضمان جودة Matrix المباشر باستخدام بيئة qa-live-shared
  • مسار ضمان جودة Telegram المباشر باستخدام عقود إيجار بيانات اعتماد Convex CI
  • pnpm qa:otel:smoke أو pnpm qa:otel:collector-smoke أو pnpm qa:prometheus:smoke أو pnpm qa:observability:smoke عندما يحتاج قياس الإصدار عن بُعد إلى إثبات محلي صريح

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

الحزمة

بيئة الحزمة هي بوابة المنتج القابل للتثبيت. يدعمها Package Acceptance والمحلل scripts/resolve-openclaw-package-candidate.mjs. يطبّع المحلل المرشح إلى ملف tarball باسم package-under-test تستهلكه اختبارات Docker الشاملة من البداية إلى النهاية، ويتحقق من مخزون الحزمة، ويسجل إصدار الحزمة وSHA-256، ويبقي مرجع عُدّة سير العمل منفصلًا عن مرجع مصدر الحزمة.

مصادر المرشح المدعومة:

  • source=npm: ‏openclaw@beta أو openclaw@latest أو إصدار OpenClaw محدد بدقة
  • source=ref: حزم فرع package_ref موثوق أو وسم أو SHA التزام كامل باستخدام عُدّة workflow_ref المحددة
  • source=url: تنزيل ملف .tgz عام عبر HTTPS مع package_sha256 مطلوب؛ تُرفض بيانات اعتماد عنوان URL ومنافذ HTTPS غير الافتراضية وأسماء المضيفين أو العناوين المحلولة الخاصة/الداخلية/ذات الاستخدام الخاص وعمليات إعادة التوجيه غير الآمنة
  • source=trusted-url: تنزيل ملف .tgz عبر HTTPS مع package_sha256 وtrusted_source_id مطلوبين من سياسة مسماة في .github/package-trusted-sources.json؛ استخدم هذا للمرايا المؤسسية المملوكة للمشرفين أو مستودعات الحزم الخاصة بدلًا من إضافة تجاوز للشبكة الخاصة على مستوى المدخلات إلى source=url
  • source=artifact: إعادة استخدام ملف .tgz رفعه تشغيل GitHub Actions آخر

يشغّل OpenClaw Release Checks قبول الحزمة باستخدام source=artifact، وعنصر حزمة الإصدار المُعدّ، وsuite_profile=custom، وdocker_lanes=doctor-switch update-channel-switch skill-install update-corrupt-plugin upgrade-survivor published-upgrade-survivor root-managed-vps-upgrade update-restart-auth plugins-offline plugin-update plugin-binding-command-escape، وtelegram_mode=mock-openai. يحتفظ قبول الحزمة بالترحيل والتحديث وترقية VPS المُدار بصلاحيات الجذر وإعادة تشغيل التحديث مع المصادقة المُهيأة وتثبيت Skills المباشر من ClawHub وتنظيف تبعيات Plugin القديمة وتركيبات Plugin غير المتصلة وتحديث Plugin وتقوية الحماية من تجاوز ربط أوامر Plugin وضمان جودة حزمة Telegram مقابل ملف tarball المحلول نفسه. تستخدم فحوص الإصدار المانعة أحدث خط أساس افتراضي للحزمة المنشورة؛ ويوسّع ملف تعريف الإصدار التجريبي مع run_release_soak=true أو release_profile=stable أو release_profile=full مسح البقاء بعد الترقية المنشورة إلى last-stable-4 بالإضافة إلى خطوط الأساس المثبتة 2026.4.23 و2026.5.2 و2026.4.15 مع سيناريوهات reported-issues. استخدم قبول الحزمة مع source=npm لمرشح منشور بالفعل، أو source=ref لملف tarball محلي لـ npm مستند إلى SHA قبل النشر، أو source=trusted-url لمرآة مؤسسية/خاصة مملوكة للمشرفين، أو source=artifact لملف tarball مُعدّ رفعه تشغيل GitHub Actions آخر.

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

قائمة التحقق الأساسية للتحقق من التحديث وPlugin هي اختبار التحديثات وPlugin. استخدمها عند تحديد مسار التحقق المحلي أو Docker أو قبول الحزمة أو فحص الإصدار الذي يثبت تغييرًا في تثبيت/تحديث Plugin أو تنظيف doctor أو ترحيل الحزمة المنشورة. الترحيل الشامل لتحديث الحزم المنشورة من كل حزمة مستقرة 2026.4.23+ هو سير عمل يدوي منفصل باسم Update Migration، وليس جزءًا من CI الكامل للإصدار.

تُحدَّد فترة التساهل القديم في قبول الحزم زمنيًا عن قصد. قد تستخدم الحزم حتى 2026.4.25 مسار التوافق لفجوات البيانات الوصفية المنشورة بالفعل إلى npm: إدخالات مخزون ضمان الجودة الخاصة المفقودة من ملف tarball، وغياب gateway install --wrapper، وغياب ملفات التصحيح في تركيبة git المستمدة من ملف tarball، وغياب update.channel المستمر، ومواقع سجلات تثبيت Plugin القديمة، وغياب استمرارية سجل تثبيت السوق، وترحيل البيانات الوصفية للإعدادات أثناء plugins update. قد تحذّر الحزمة المنشورة 2026.4.26 من ملفات طابع البيانات الوصفية للبناء المحلي التي شُحنت بالفعل. يجب أن تستوفي الحزم اللاحقة عقود الحزم الحديثة؛ وتؤدي الفجوات نفسها فيها إلى فشل التحقق من الإصدار.

استخدم ملفات تعريف قبول الحزمة الأوسع عندما يتعلق سؤال الإصدار بحزمة فعلية قابلة للتثبيت:

bash
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/الوكيل الفرعي، وبحث الويب من OpenAI، وOpenWebUI
  • full: أجزاء مسار إصدار Docker مع OpenWebUI
  • custom: قائمة docker_lanes الدقيقة لإعادات التشغيل المركزة

لإثبات Telegram لمرشح الحزمة، فعّل telegram_mode=mock-openai أو telegram_mode=live-frontier في قبول الحزمة. يمرر سير العمل أرشيف package-under-test المحلول إلى مسار Telegram؛ ولا يزال سير عمل Telegram المستقل يقبل محدد npm منشورًا لفحوص ما بعد النشر.

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

بالنسبة إلى نشر الإصدار التجريبي، وlatest، وPlugin، وإصدار GitHub، والمنصات، يُعد OpenClaw Release Publish نقطة الدخول الاعتيادية التي تُجري التغييرات. لا يستخدم مسار الإصدار الممتد المستقر الشهري .33+ والخاص بـ npm هذا المنسق. ينسّق سير العمل الاعتيادي تدفقات عمل الناشر الموثوق بالترتيب الذي يحتاج إليه الإصدار:

  1. استخرج وسم الإصدار وحدد SHA للالتزام الخاص به.
  2. تحقق من إمكانية الوصول إلى الوسم من main أو release/* (أو من فرع Tideclaw alpha للإصدارات التمهيدية من نوع alpha).
  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 المحفوظ بعد التحقق من full_release_validation_run_id المحفوظ ومحاولة التشغيل الدقيقة.
  7. بالنسبة إلى الإصدارات المستقرة، أنشئ إصدار GitHub أو حدّثه كمسودة، وشغّل Windows Node Release باستخدام windows_node_tag الصريح وقيم windows_node_installer_digests المعتمدة للمرشح، وتحقق من أصول مثبت Windows ومجاميع التحقق القياسية. شغّل أيضًا Android Release لبناء ملف APK الموقّع الخاص بالوسم الدقيق، مع مجموع التحقق وإثبات المصدر. تحقق من عقدَي الأصول الأصليين قبل نشر المسودة.

مثال على نشر إصدار تجريبي:

bash
gh workflow run openclaw-release-publish.yml \  --ref main \  -f tag=vYYYY.M.PATCH-beta.N \  -f preflight_run_id=<successful-openclaw-npm-preflight-run-id> \  -f full_release_validation_run_id=<successful-full-release-validation-run-id> \  -f full_release_validation_run_attempt=<successful-full-release-validation-run-attempt> \  -f npm_dist_tag=beta

نشر إصدار مستقر إلى وسم التوزيع التجريبي الافتراضي:

bash
gh workflow run openclaw-release-publish.yml \  --ref main \  -f tag=vYYYY.M.PATCH \  -f windows_node_tag=vX.Y.Z \  -f windows_node_installer_digests='{"OpenClawCompanion-Setup-x64.exe":"sha256:<approved-x64-sha256>","OpenClawCompanion-Setup-arm64.exe":"sha256:<approved-arm64-sha256>"}' \  -f preflight_run_id=<successful-openclaw-npm-preflight-run-id> \  -f full_release_validation_run_id=<successful-full-release-validation-run-id> \  -f full_release_validation_run_attempt=<successful-full-release-validation-run-attempt> \  -f npm_dist_tag=beta

الترقية المباشرة للإصدار المستقر إلى latest صريحة:

bash
gh workflow run openclaw-release-publish.yml \  --ref main \  -f tag=vYYYY.M.PATCH \  -f windows_node_tag=vX.Y.Z \  -f windows_node_installer_digests='{"OpenClawCompanion-Setup-x64.exe":"sha256:<approved-x64-sha256>","OpenClawCompanion-Setup-arm64.exe":"sha256:<approved-arm64-sha256>"}' \  -f preflight_run_id=<successful-openclaw-npm-preflight-run-id> \  -f full_release_validation_run_id=<successful-full-release-validation-run-id> \  -f full_release_validation_run_attempt=<successful-full-release-validation-run-attempt> \  -f npm_dist_tag=latest

استخدم تدفقي العمل منخفضَي المستوى Plugin NPM Release وPlugin ClawHub Release فقط لأعمال الإصلاح أو إعادة النشر المركزة. يرفض OpenClaw Release Publish القيمة plugin_publish_scope=selected عندما تكون publish_openclaw_npm=true، كي لا تُشحن الحزمة الأساسية من دون كل Plugin رسمي قابل للنشر، بما في ذلك @openclaw/diffs-language-pack. لإصلاح Plugin محدد، عيّن publish_openclaw_npm=false مع plugin_publish_scope=selected وplugins=@openclaw/name، أو شغّل سير العمل الفرعي مباشرةً.

يمثل تمهيد النشر الأول إلى ClawHub الاستثناء: شغّل Plugin ClawHub New من main الموثوق ومرر SHA الكامل للإصدار المستهدف عبر ref. لا تشغّل سير عمل التمهيد نفسه مطلقًا من وسم الإصدار أو فرعه:

bash
gh workflow run plugin-clawhub-new.yml \  --ref main \  -f plugins=@openclaw/name \  -f ref=<full-40-character-release-sha> \  -f pretag_validation=true \  -f dry_run=true

يتطلب التحقق السابق للوسم dry_run=true، ويرفض مدخلات وسم الإصدار وتشغيل الأصل، ولا يقبل إلا هدفًا دقيقًا يمكن الوصول إليه من main أو release/*. وهو لا يحمّل بيانات اعتماد ClawHub، ولا ينشر وحدات بايت الحزمة، ولا يغيّر إعدادات الناشر الموثوق. ومع ذلك، يحل سير العمل خطة السجل المباشر، ويستخرج الهدف ويحزمه فقط في مهمة بلا أسرار، ويُنشئ سلسلة أدوات ClawHub المقفلة، ويتحقق من الأثر غير القابل للتغيير ومن اسم الحزمة المختصر/هويتها قبل وجود وسم الإصدار. وافق على بيئة clawhub-plugin-bootstrap فقط بعد انتهاء مهام الحزم الخالية من الأسرار؛ فمهمة التحقق المحمية هذه لا تتضمن بيانات اعتماد أو أوامر تغيير.

يجب أن يتضمن التشغيل التجريبي المعتمد أو التمهيد الفعلي بعد وضع الوسم وسم الإصدار الدقيق، إضافةً إلى معرّف تشغيل OpenClaw Release Publish الأصل، ومحاولته، وفرعه. يشهد الأصل على SHA لسير عمله نفسه وعلى SHA دقيق منفصل لـmain الموثوق من أجل Plugin ClawHub New؛ ويجب أن يتطابق التشغيل الفرعي وكل موافقة على البيئة المحمية مع SHA الفرعي المعتمد. يُعاد التحقق من وسم الإصدار قبل كل محاولة نشر وتغيير للناشر الموثوق.

ترفع مهمة الحزم أثرًا واحدًا غير قابل للتغيير، ويُنقل اسمه، ومعرّف/ملخص أثر Actions، وتشغيل/محاولة المُنتِج، وSHA الهدف، وقيمة SHA-256/الحجم لأرشيف كل حزمة إلى مهمات التحقق والمهمات المحمية. تستخرج المهمة المحمية أدوات main الموثوقة فقط، وتتحقق من مجموعة خصائص الأثر عبر GitHub API، وتُنزّل باستخدام معرّف الأثر الدقيق، وتعيد تجزئة كل أرشيف، وتتحقق من مسارات TAR المحلية ومن هوية الحزمة وفق قواعد التطبيع USTAR الخاصة بـCLI المثبّت. ثم يجتاز كل مرشح تشغيلًا تجريبيًا للنشر باستخدام CLI المثبّت، ويعود هذا التشغيل قبل البحث في السجل أو المصادقة. يحد المرشح الأولي في مهمة بيانات الاعتماد حزم ClawPacks المضغوطة عند 120 MiB، وإجمالي حمولة الملفات عند 50 MiB، وبيانات TAR الموسعة عند 64 MiB، وعدد إدخالات TAR عند 10,000. يظل إصلاح الناشر الموثوق للحزمة الموجودة مخصصًا للإعداد فقط، لكنه لا يزال يحزم الهدف ويتطلب الوسم المطلوب مع تطابق وحدات بايت السجل وبياناته الوصفية تطابقًا دقيقًا قبل تغيير إعدادات الناشر الموثوق. ينزّل التحقق اللاحق للنشر أثر ClawHub ويشترط تطابق SHA-256 والحجم. يجوز لاسترداد إعادة تشغيل المهام الفاشلة إعادة استخدام أثر حزمة من محاولة سابقة فقط عندما تكون مهمة المُنتِج الدقيقة قد اكتملت بنجاح. كما يربط الدليل النهائي إصدار ClawHub المقفل، وقيمة SHA-256 للقفل، وسلامة npm. يستلزم أي عدم تطابق إصدار حزمة جديدًا.

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

يقبل OpenClaw NPM Release هذه المدخلات التي يتحكم فيها المشغّل:

  • tag: وسم إصدار مطلوب مثل v2026.4.2، أو v2026.4.2-1، أو v2026.4.2-beta.1، أو v2026.4.2-alpha.1؛ وعندما تكون preflight_only=true، يجوز أن يكون أيضًا SHA الكامل الحالي المكوّن من 40 محرفًا لالتزام فرع سير العمل من أجل الفحص التمهيدي المخصص للتحقق فقط
  • preflight_only: ‏true للتحقق/البناء/الحزم فقط، وfalse لمسار النشر الفعلي
  • preflight_run_id: معرّف تشغيل تمهيدي ناجح موجود، وهو مطلوب في مسار النشر الفعلي كي يعيد سير العمل استخدام الأرشيف المُعد بدلًا من إعادة بنائه
  • full_release_validation_run_id: معرّف تشغيل Full Release Validation ناجح لهذا الوسم/SHA، وهو مطلوب للنشر الفعلي. يجوز أن تستمر عمليات نشر الإصدار التجريبي اعتمادًا على الفحص التمهيدي وحده مع تحذير، لكن ترقية الإصدار المستقر/latest لا تزال تتطلبه.
  • full_release_validation_run_attempt: محاولة التشغيل الموجبة الدقيقة المقترنة بـfull_release_validation_run_id؛ وهي مطلوبة متى قُدّم معرّف التشغيل، كي لا تتمكن إعادات التشغيل من تغيير دليل التفويض أثناء النشر.
  • release_publish_run_id: معرّف تشغيل OpenClaw Release Publish المعتمد؛ وهو مطلوب عندما يشغّل سير العمل هذا ذلك الأصل (استدعاءات النشر الفعلي بواسطة جهة آلية)
  • plugin_npm_run_id: معرّف تشغيل Plugin NPM Release ناجح عند الرأس الدقيق؛ وهو مطلوب للنشر الفعلي لحزمة extended-stable الأساسية
  • npm_dist_tag: وسم npm المستهدف لمسار النشر؛ يقبل alpha، أو beta، أو latest، أو extended-stable، وتكون قيمته الافتراضية beta. يجب أن تستخدم الرقعة النهائية 33 وما بعدها extended-stable؛ وافتراضيًا، يرفض extended-stable الرقع الأقدم، ويرفض دائمًا الوسوم غير النهائية.
  • bypass_extended_stable_guard: قيمة منطقية للاختبار فقط، وقيمتها الافتراضية false؛ ومع npm_dist_tag=extended-stable، تتجاوز أهلية الإصدار الممتد المستقر الشهري مع الحفاظ على فحوص هوية الإصدار، والأثر، والموافقة، والقراءة اللاحقة.

يقبل Plugin NPM Release القيمة npm_dist_tag=default لسلوك الإصدار الحالي، أو npm_dist_tag=extended-stable للمسار الشهري المحمي. يتطلب خيار الإصدار الممتد المستقر publish_scope=all-publishable، ومدخل plugins فارغًا، ورقعة نهائية عند 33 أو أعلى، وفرع extended-stable/YYYY.M.33 القياسي عند رأسه الدقيق. وهو لا ينقل مطلقًا وسمَي Plugin ‏latest أو beta. تتلقى إصدارات الحزم الجديدة extended-stable ذريًا عبر النشر الموثوق باستخدام OIDC ‏(npm publish --tag extended-stable)؛ ولا يستخدم سير العمل المصدري هذا الأمر npm dist-tag add المعتمد على المصادقة بالرمز. تتجاوز إعادات المحاولة الإصدارات الدقيقة الموجودة مسبقًا في npm، ثم تفشل بشكل مغلق ما لم تؤكد القراءة اللاحقة الكاملة تقارب كل حزمة دقيقة ووسم extended-stable.

يقبل OpenClaw Release Publish هذه المدخلات التي يتحكم فيها المشغّل:

  • tag: وسم الإصدار المطلوب؛ ويجب أن يكون موجودًا بالفعل
  • preflight_run_id: معرّف تشغيل تمهيدي ناجح لـOpenClaw NPM Release؛ وهو مطلوب عندما تكون publish_openclaw_npm=true أو plugin_publish_scope=all-publishable
  • full_release_validation_run_id: معرّف تشغيل Full Release Validation ناجح؛ وهو مطلوب عندما تكون publish_openclaw_npm=true أو plugin_publish_scope=all-publishable
  • full_release_validation_run_attempt: المحاولة الموجبة الدقيقة المقترنة بـfull_release_validation_run_id؛ وهي مطلوبة متى قُدّم معرّف التشغيل
  • windows_node_tag: وسم إصدار openclaw/openclaw-windows-node الدقيق وغير التمهيدي؛ وهو مطلوب لنشر OpenClaw المستقر
  • windows_node_installer_digests: خريطة JSON مدمجة ومعتمدة للمرشح تربط أسماء مثبتات Windows الحالية بملخصات sha256: المثبتة الخاصة بها؛ وهي مطلوبة لنشر OpenClaw المستقر
  • npm_telegram_run_id: معرّف تشغيل NPM Telegram Beta E2E ناجح اختياري لتضمينه في دليل الإصدار النهائي
  • npm_dist_tag: وسم npm المستهدف لحزمة OpenClaw، وهو أحد alpha، أو beta، أو latest
  • plugin_publish_scope: قيمته الافتراضية all-publishable؛ استخدم selected فقط لأعمال الإصلاح المركزة الخاصة بـPlugin وحده مع publish_openclaw_npm=false
  • plugins: أسماء حزم @openclaw/* مفصولة بفواصل عندما تكون plugin_publish_scope=selected
  • publish_openclaw_npm: قيمته الافتراضية true؛ عيّنه إلى false فقط عند استخدام سير العمل كمنسق إصلاح خاص بـPlugin وحده
  • release_profile: ملف تعريف تغطية الإصدار المستخدم لملخصات دليل الإصدار؛ قيمته الافتراضية from-validation، التي تقرؤه من بيان التحقق، أو تجاوزه باستخدام beta، أو stable، أو full
  • wait_for_clawhub: قيمته الافتراضية false كي لا يتسبب المسار الجانبي لـClawHub في حظر توفر npm؛ عيّنه إلى true فقط عندما يجب أن يتضمن اكتمال سير العمل اكتمال ClawHub

يقبل OpenClaw Release Checks هذه المدخلات التي يتحكم فيها المشغّل:

  • ref: فرع أو وسم أو SHA كامل للالتزام المطلوب التحقق منه. تتطلب الفحوص التي تحمل أسرارًا أن يكون الالتزام المحلول قابلًا للوصول من فرع OpenClaw أو وسم إصدار.
  • run_release_soak: الاشتراك في اختبار تحمّل شامل يتضمن الفحوص المباشرة/E2E، ومسار إصدار Docker، واستمرارية الترقية عبر جميع الإصدارات السابقة، وذلك لفحوص الإصدار التجريبي. ويُفرض تفعيله بواسطة release_profile=stable وrelease_profile=full.

القواعد:

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

تسلسل الإصدار المستقر العادي beta/latest

هذا التسلسل القديم مخصص للإصدار المنسَّق العادي الذي يشمل أيضًا Plugins وإصدار GitHub وWindows وأعمال المنصات الأخرى. وهو ليس مسار extended-stable الشهري المخصص لـ npm فقط بإصدارات .33+ والموثَّق في أعلى هذه الصفحة.

عند إصدار نسخة مستقرة عادية ومنسَّقة:

  1. شغّل OpenClaw NPM Release مع preflight_only=true. قبل وجود وسم، يمكنك استخدام SHA الكامل للالتزام الحالي في فرع سير العمل لإجراء تشغيل تجريبي للفحص المسبق مخصص للتحقق فقط.
  2. اختر npm_dist_tag=beta للمسار العادي الذي يبدأ بـ beta، أو latest فقط عندما تريد عمدًا النشر المستقر مباشرةً.
  3. شغّل Full Release Validation على فرع الإصدار أو وسم الإصدار أو SHA الكامل للالتزام عندما تريد CI العادي إلى جانب تغطية حية لذاكرة التخزين المؤقت للموجّهات وDocker وQA Lab وMatrix وTelegram من سير عمل يدوي واحد. إذا كنت تحتاج عمدًا إلى مخطط الاختبارات العادي الحتمي فقط، فشغّل سير العمل اليدوي CI على مرجع الإصدار بدلًا من ذلك.
  4. حدّد وسم الإصدار openclaw/openclaw-windows-node الدقيق غير الخاص بإصدار مسبق، الذي يجب شحن أدوات التثبيت الموقّعة الخاصة به لبنيتَي x64 وARM64. احفظه باسم windows_node_tag، واحفظ خريطة الملخصات المتحقق منها لأدوات التثبيت باسم windows_node_installer_digests. تسجّل أداة الإصدار المرشح المساعدة كليهما وتضمّنهما في أمر النشر الذي تنشئه.
  5. احفظ قيم preflight_run_id وfull_release_validation_run_id وfull_release_validation_run_attempt الدقيقة من التشغيل الناجح.
  6. شغّل OpenClaw Release Publish من main الموثوق باستخدام tag نفسه وnpm_dist_tag نفسها، وwindows_node_tag المحدد، وقيمة windows_node_installer_digests المحفوظة الخاصة به، وقيم preflight_run_id وfull_release_validation_run_id وfull_release_validation_run_attempt المحفوظة. ينشر Plugins المفصولة خارجيًا إلى npm وClawHub قبل ترقية حزمة OpenClaw على npm.
  7. إذا وصل الإصدار إلى beta، فاستخدم سير العمل openclaw/releases/.github/workflows/openclaw-npm-dist-tags.yml لترقية ذلك الإصدار المستقر من beta إلى latest.
  8. إذا نُشر الإصدار عمدًا مباشرةً إلى latest وكان ينبغي أن يتبع beta البنية المستقرة نفسها فورًا، فاستخدم سير عمل الإصدار نفسه لتوجيه وسمَي التوزيع إلى الإصدار المستقر، أو دع مزامنة الإصلاح الذاتي المجدولة تنقل beta لاحقًا.

يُدار تعديل وسم التوزيع في مستودع سجل الإصدارات لأنه لا يزال يتطلب NPM_TOKEN، بينما يحتفظ مستودع المصدر بالنشر المعتمد على OIDC فقط. وبذلك يظل كل من مسار النشر المباشر ومسار الترقية الذي يبدأ بـ beta موثَّقًا ومرئيًا للمشغّلين.

إذا اضطر أحد المشرفين إلى الرجوع إلى مصادقة npm المحلية، فيجب تشغيل أي أوامر لواجهة 1Password CLI (op) داخل جلسة tmux مخصصة فقط. لا تستدعِ op مباشرةً من صدفة الوكيل الرئيسية؛ فإبقاؤه داخل tmux يجعل المطالبات والتنبيهات ومعالجة OTP قابلة للملاحظة ويمنع تكرار تنبيهات المضيف.

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

يستخدم المشرفون وثائق الإصدار الخاصة في openclaw/maintainers/release/README.md بوصفها دليل التشغيل الفعلي.

ذو صلة

Was this useful?
On this page

On this page