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

Release process

سیاست انتشار

OpenClaw چهار کانال به‌روزرسانی در معرض کاربر ارائه می‌کند:

  • stable: انتشار عادی ترویج‌شده در npm latest
  • extended-stable: خط نگهداشت ماه تکمیل‌شده قبلی .33+ در npm extended-stable
  • beta: برچسب‌های پیش‌انتشار در npm beta
  • dev: سر متغیر main

extended-stable، Gateway ماه قبلی، Pluginهای رسمی npm و تصاویر Docker را بدون جابه‌جایی انتخاب‌گرهای عادی latest یا main منتشر می‌کند.

بیلدهای آلفای Tideclaw مسیر پیش‌انتشار داخلی جداگانه‌ای هستند (dist-tag در npm با نام alpha) که در ورودی‌های گردش‌کار NPM و باکس‌های تست انتشار پوشش داده شده‌اند.

نام‌گذاری نسخه

  • نسخه انتشار ماهانه extended-stable برای Gateway: 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 به‌معنای توزیع پشتیبانی‌شده Gateway برای ماه قبلی است که از پچ 33 آغاز می‌شود؛ پچ 34 و پچ‌های بعدی، انتشارهای نگهداشت آن خط ماهانه هستند
  • انتشارهای نهایی عادی و اصلاحی عادی به‌طور پیش‌فرض در npm با beta منتشر می‌شوند؛ متصدیان انتشار می‌توانند latest را صریحاً هدف بگیرند یا یک بیلد بتای ارزیابی‌شده را بعداً ترویج کنند
  • extended-stable برای Gateway، هسته، هر Plugin رسمی قابل‌انتشار در npm، و تصاویر Docker آن را با یک نسخه دقیق منتشر می‌کند؛ گردش‌کار اختصاصی زیر را ببینید.
  • هر انتشار نهایی عادی، بسته npm، برنامه macOS، فایل APK مستقل و امضاشده Android و نصب‌کننده‌های امضاشده Windows Hub را با هم عرضه می‌کند. انتشارهای بتا معمولاً ابتدا مسیر npm/بسته را اعتبارسنجی و منتشر می‌کنند و ساخت/امضا/محضری‌سازی/ترویج برنامه بومی، مگر در صورت درخواست صریح، برای انتشار نهایی عادی محفوظ می‌ماند.

تناوب انتشار

  • انتشارها ابتدا به بتا می‌روند؛ stable تنها پس از اعتبارسنجی آخرین بتا ارائه می‌شود
  • نگه‌دارندگان معمولاً انتشارها را از شاخه release/YYYY.M.PATCH که از main جاری ایجاد شده است، انجام می‌دهند تا اعتبارسنجی و اصلاحات انتشار، توسعه جدید در main را مسدود نکند
  • اگر یک برچسب بتا push یا منتشر شده باشد و به اصلاح نیاز داشته باشد، نگه‌دارندگان به‌جای حذف یا بازسازی برچسب قدیمی، برچسب -beta.N بعدی را ایجاد می‌کنند
  • رویه دقیق انتشار، تأییدها، اعتبارنامه‌ها و یادداشت‌های بازیابی فقط ویژه نگه‌دارندگان است

انتشار ماهانه extended-stable برای Gateway

برای ماه تکمیل‌شده YYYY.M، extended-stable/YYYY.M.33 را ایجاد و .33+ را از آن شاخه منتشر کنید. برچسب، شاخه، checkout، نسخه بسته، پیش‌بررسی و اعتبارسنجی باید یک commit را مشخص کنند. پیش از .33، شاخه محافظت‌شده main باید نسخه نهایی ماهی بعدتر با پچی پایین‌تر از 33 را در بر داشته باشد؛ پچ‌های نگهداشت بعدی همچنان واجد شرایط هستند.

آماده‌سازی و پایدارسازی نامزد

بازه ممیزی‌نشده خط اصلی را ممیزی کنید، کار امنیتی خصوصی را تطبیق دهید، مجموعه‌ای محدود از backportها را تأیید کنید و یک PR هماهنگ را ادغام کنید. شاخه متعارف را مستقیماً push نکنید.

در شاخه متعارف، YYYY.M.P را تنظیم کنید، pnpm release:prep را اجرا کنید و آن نسخه را در هر Plugin رسمی قابل‌انتشار الزامی کنید. از دفترکل تأییدشده، یک بخش کامل ## YYYY.M.P را با ### Highlights، ### Changes و ### Fixes تولید و commit کنید و برای backportهای معادل، به PRهای اصلی ادغام‌شده main ارجاع دهید. پیش‌بررسی، بخش مفقود یا خالی را رد می‌کند.

واحد کامل کانال انتشار Docker از main جاری را منتقل کنید: گردش‌کار، ترویج‌کننده، سیاست، طبقه‌بند مشترک، تست‌ها و اعتبارسنجی گردش‌کار. GitHub گردش‌کارهای برچسب را از commit برچسب‌گذاری‌شده بارگیری می‌کند؛ یک کپی ناقص ممکن است پس از بیلد شکست بخورد یا نام‌های مستعار عادی را جابه‌جا کند. بررسی‌های متمرکز را اجرا کنید.

SHA کامل نوک شاخه را تثبیت کنید. پیش از برچسب‌گذاری، بایت‌های دقیق npm آن را پیش‌بررسی کنید و Full Release Validation را روی آن SHA اجرا کنید:

bash
RELEASE_SHA="$(git rev-parse HEAD)" gh workflow run openclaw-npm-release.yml \  --ref extended-stable/YYYY.M.33 \  -f tag="$RELEASE_SHA" \  -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

فرم SHA فقط برای پیش‌بررسی است. اعتبارسنجی را روی شاخه متعارف اجرا کنید؛ انتشار ارجاع گردش‌کار، SHA سر/هدف، شناسه اجرا و تلاش آن را مقید می‌کند. هر دو شناسه و run_attempt موفق را ذخیره کنید؛ شواهد release-ci/* را رد کنید.

پیش از ویرایش، شکست‌ها را طبقه‌بندی کنید:

  • محصول: یک PR دیگر برای backport تأییدشده ادغام کنید.
  • ابزار هدف تثبیت‌شده: فقط کوچک‌ترین اصلاح سازگاری را backport کنید که محصول قدیمی را بدون تغییر تست کند.
  • ارائه‌دهنده، تأیید، اجراکننده یا سرویس: نامزد را بدون تغییر نگه دارید و از مسیر تلاش مجدد محدود استفاده کنید.

هر تغییر شاخه، هر دو دروازه را نامعتبر می‌کند. پس از عبور آن‌ها، الزام کنید که نوک همچنان برابر RELEASE_SHA باشد، سپس vYYYY.M.P امضاشده را push کنید. تغییرات بعدی به پچ بعدی نیاز دارند؛ هرگز برچسب را جابه‌جا یا حذف نکنید. push آن، Docker Release را آغاز می‌کند.

انتشار بسته‌های npm

هر Plugin رسمی قابل‌انتشار در npm را از همان SHA منتشر کنید و شناسه اجرای موفق را ذخیره کنید:

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، از جمله بسته‌های بدون تغییر را پوشش می‌دهد و هر نسخه دقیق و انتخاب‌گر را تأیید می‌کند. اجرای مجدد از نسخه‌های منتشرشده دوباره استفاده می‌کند.

سپس tarball آماده‌شده هسته را با هر سه هویت اجرای ذخیره‌شده منتشر کنید:

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>

فقط برای تمرین غیرتولیدی، -f bypass_extended_stable_guard=true را به پیش‌بررسی و انتشار اضافه کنید. این گزینه فقط نگهبان ماه را دور می‌زند و هرگز بررسی‌های ارجاع متعارف، برابری SHA/برچسب/نسخه، منشأ، تأیید یا بازخوانی را دور نمی‌زند. هرگز از آن در محیط تولید استفاده نکنید.

تأیید و بازیابی

از یک checkout تمیز و جداگانه از main جاری، نه شاخه تثبیت‌شده، اجرا کنید:

bash
node --import tsx scripts/openclaw-npm-postpublish-verify.ts YYYY.M.Pnpm view openclaw@YYYY.M.P version --userconfig "$(mktemp)"npm view openclaw@extended-stable version --userconfig "$(mktemp)"

برای شاخه متعارف، امضاها و منشأ npm و نیز اتصال انتشار، پیش‌بررسی و digest فایل tarball به SHA انتشار را الزامی کنید. هر دو فرمان باید YYYY.M.P را برگردانند. هر بسته آماده‌شده هسته و هر Plugin رسمی all-publishable را در نسخه و انتخاب‌گر دقیق آن تأیید کنید.

اگر فقط انتخاب‌گر ریشه شکست خورد، از فرمان تعمیر تولیدشده npm dist-tag add openclaw@YYYY.M.P extended-stable که در خلاصه گردش‌کار چاپ شده است استفاده کنید. انتخاب‌گرهای Plugin موجود یا دیگر انتخاب‌گرهای هسته آماده‌شده را با ابزار تأییدشده و ایزوله از اعتبارنامه تعمیر کنید؛ منبع OIDC نمی‌تواند آن‌ها را تغییر دهد. هرگز یک نسخه تغییرناپذیر را بازنشر نکنید.

الزام کنید Docker Release تصاویر دقیق پیش‌فرض، slim، مرورگر و معماری را در GHCR و Docker Hub، از جمله گواهی‌ها و نسخه‌های پلتفرم، تأیید کند. این مورد باید فقط extended-stable، extended-stable-slim و extended-stable-browser را بر اساس digest جلو ببرد؛ نام‌های مستعار عادی بدون تغییر می‌مانند و بازگشت خودکار رد می‌شود.

برای تعمیر نام مستعار، Docker Channel Promotion نیازمند تأیید را از main جاری و با برچسب اجرا کنید. این کار بررسی‌های digest، گواهی و پلتفرم را تکرار می‌کند، اجازه بازگشت صریح می‌دهد و هرگز تصاویر را دوباره نمی‌سازد.

Slack، Discord و Codex سطوح پشتیبانی مستند اولیه هستند، نه یک فهرست مجاز انتشار: هر Plugin رسمی قابل‌انتشار در npm عرضه می‌شود. فقط چک‌لیست عادی مالک beta/latest، GitHub Releases، ClawHub، برنامه‌های بومی، موبایل، وب‌سایت و dist-tagهای خصوصی است؛ این مراحل را برای این مسیر Gateway اجرا نکنید.

چک‌لیست متصدی انتشار عادی

این چک‌لیست شکل عمومی جریان انتشار است. اعتبارنامه‌های خصوصی، امضا، محضری‌سازی، بازیابی dist-tag و جزئیات بازگشت اضطراری در راهنمای اجرای انتشار ویژه نگه‌دارندگان باقی می‌ماند.

  1. از main جاری آغاز کنید: آخرین تغییرات را pull کنید، تأیید کنید commit هدف push شده است و تأیید کنید پایپ‌لاین CI مربوط به main به‌اندازه کافی سبز است که بتوان از آن شاخه ساخت.

  2. release/YYYY.M.PATCH را از آن commit ایجاد کنید. backportها اختیاری هستند؛ فقط مجموعه انتخاب‌شده توسط متصدی را اعمال کنید. همه محل‌های نسخه لازم را افزایش دهید، pnpm release:prep را اجرا کنید، اصلاحات انتشار و forward-portهای الزامی را تکمیل کنید و src/plugins/compat/registry.ts به‌علاوه src/commands/doctor/shared/deprecation-compat.ts را بازبینی کنید.

  3. commit کامل محصول پیش از changelog را به‌عنوان Code SHA تثبیت کنید. پیش‌بررسی قطعی منبع را اجرا کنید، سپس از node scripts/full-release-validation-at-sha.mjs --sha <code-sha> --target-ref release/YYYY.M.PATCH استفاده کنید. این کار ابزار گردش‌کار مورداعتماد را ثابت می‌کند، درحالی‌که ماتریس کامل Vitest، Docker، QA، بسته و عملکرد دقیقاً Code SHA را هدف می‌گیرد.

  4. پیش از ویرایش، شکست‌ها را طبقه‌بندی کنید. شکست محصول/کد یک Code SHA جدید ایجاد می‌کند و برای آن SHA به اعتبارسنجی کامل سبز نیاز دارد. شکست گردش‌کار، چارچوب، اعتبارنامه، تأیید یا زیرساخت در سطح مالک خود اصلاح و در برابر همان Code SHA دوباره اجرا می‌شود.

  5. تنها پس از سبزشدن Code SHA، بخش بالایی CHANGELOG.md را از PRهای ادغام‌شده و commitهای مستقیم پس از آخرین برچسب عرضه‌شده قابل‌دسترسی تولید کنید. مدخل‌ها را کاربرمحور و بدون تکرار نگه دارید. هنگامی که یک برچسب عرضه‌شده واگرا یا forward-port بعدی، PRهای ازپیش‌منتشرشده را دوباره مرتبط می‌کند، آن را صریحاً به‌صورت --shipped-ref ارسال کنید.

  6. فقط CHANGELOG.md را commit کنید. این commit همان Release SHA است. تفاوت کامل از Code SHA تا Release SHA باید دقیقاً CHANGELOG.md باشد؛ هر مسیر تغییریافته دیگر، انتشار را به مرحله 2 بازمی‌گرداند.

  7. Full Release Validation مقید به SHA را برای Release SHA و با استفاده مجدد از شواهد اجرا کنید. والد سبک‌وزن باید changelog-only-release-v1 را ثبت کند، به Code SHA سبز اشاره کند و هیچ مسیر فرزند محصولی را dispatch نکند. این کار از شواهد محصول دوباره استفاده می‌کند؛ از بایت‌های بسته دوباره استفاده نمی‌کند.

  8. OpenClaw NPM Release را با preflight_only=true در برابر Release SHA/برچسب اجرا کنید. preflight_run_id موفق را ذخیره کنید. این کار بایت‌های دقیق بسته را که changelog نهایی را در بر دارند، می‌سازد و بررسی می‌کند.

  9. Release SHA را برچسب‌گذاری کنید، سپس helper نامزد را با والد اعتبارسنجی موفق Release-SHA و پیش‌بررسی npm اجرا کنید، به‌جای آنکه هرکدام را دوباره dispatch کنید:

    bash
    pnpm release:candidate -- \  --tag vYYYY.M.PATCH-beta.N \  --full-release-run <release-sha-validation-run-id> \  --npm-preflight-run <preflight-run-id> \  --skip-dispatch

    برای انتشار پایدار، --windows-node-tag vX.Y.Z را نیز ارسال کنید. این ابزار کمکی منشأ یادداشت‌های انتشار، بایت‌های پیش‌پرواز npm، مدرک نصب/به‌روزرسانی Parallels، مدرک بسته Telegram و برنامه‌های انتشار Plugin را تأیید می‌کند و سپس فرمان انتشار را نمایش می‌دهد.

    OpenClaw Release Publish بسته‌های Plugin انتخاب‌شده یا همهٔ بسته‌های قابل‌انتشار را به‌صورت موازی به npm و همان مجموعه را به ClawHub ارسال می‌کند، سپس پس از موفقیت انتشار Pluginها در npm، آرتیفکت پیش‌پرواز آماده‌شدهٔ npm مربوط به OpenClaw را با dist-tag منطبق ارتقا می‌دهد. محل پرداخت انتشار همچنان ریشهٔ محصول/داده باقی می‌ماند، درحالی‌که برنامه‌ریزی و تأیید نهایی از محل پرداخت دقیق و مورداعتماد منبع گردش‌کار اجرا می‌شوند تا یک کامیت انتشار قدیمی نتواند بی‌سروصدا از ابزار انتشار منسوخ استفاده کند. پیش از شروع هر فرایند فرزند انتشار، متن دقیق انتشار GitHub را رندر و ذخیره می‌کند. وقتی بخش کامل و منطبق CHANGELOG.md در محدودیت 125,000 نویسه‌ای GitHub و سقف ایمنی منطبق 125,000 بایتی رندرکننده جا شود، صفحه دقیقاً همان بخش ## YYYY.M.PATCH را همراه با عنوانش دربر می‌گیرد. وقتی بخش منبع جا نشود، صفحه یادداشت‌های ویراستاری گروه‌بندی‌شده را عیناً نگه می‌دارد و سابقهٔ مشارکت بیش‌ازحد بزرگ را با پیوندی پایدار به سابقهٔ کامل در CHANGELOG.md سنجاق‌شده به تگ جایگزین می‌کند؛ سوابق ناقص و موارد فهرست بریده‌شده هرگز منتشر نمی‌شوند. گردش‌کار پیش از افزودن ### Release verification متن کامل یا فشرده را انتخاب می‌کند؛ اگر دنبالهٔ مدارک از محدودیت عبور کند، متن مرجع را نگه می‌دارد و به مدرک تغییرناپذیر پیوست‌شده متکی می‌شود. انتشارهای پایداری که با npm latest منتشر می‌شوند، به آخرین انتشار GitHub تبدیل می‌شوند، درحالی‌که انتشارهای نگه‌داری پایدار که روی npm beta نگه داشته می‌شوند، با GitHub latest=false ایجاد می‌شوند. گردش‌کار همچنین مدارک وابستگی پیش‌پرواز، مانیفست اعتبارسنجی کامل و مدارک تأیید رجیستری پس از انتشار را برای واکنش به رخدادهای پس از انتشار در انتشار GitHub بارگذاری می‌کند. شناسه‌های اجرای فرزند را فوراً نمایش می‌دهد، دروازه‌های محیط انتشار را که توکن گردش‌کار مجاز به تأییدشان است به‌طور خودکار تأیید می‌کند، کارهای فرزند ناموفق را همراه با انتهای لاگ‌ها خلاصه می‌کند، صفحهٔ پیش‌نویس انتشار GitHub را از ابتدا می‌سازد و آرتیفکت‌های Windows و Android را هم‌زمان با انتشار npm مربوط به OpenClaw ارتقا می‌دهد، پس از موفقیت آن مراحل صفحهٔ انتشار و مدارک وابستگی را نهایی می‌کند، هرگاه OpenClaw در npm منتشر شود منتظر ClawHub می‌ماند، سپس تأییدکنندهٔ بتای main مورداعتماد را اجرا می‌کند و مدارک پس از انتشار مربوط به انتشار GitHub، بستهٔ npm، بسته‌های انتخاب‌شدهٔ Plugin در npm، بسته‌های انتخاب‌شدهٔ ClawHub، شناسه‌های اجرای گردش‌کار فرزند و شناسهٔ اختیاری اجرای NPM مربوط به Telegram را بارگذاری می‌کند. تأییدکنندهٔ راه‌اندازی اولیهٔ ClawHub به مسیر و SHA دقیق گردش‌کار main مورداعتماد، تلاش‌های اجرای تولیدکننده و پایانی، SHA انتشار، مجموعهٔ بسته‌های درخواست‌شده، چندتایی تغییرناپذیر آرتیفکت بسته و آرتیفکت بازخوانی پایانی رجیستری نیاز دارد؛ اجرای موفق قدیمی مبتنی بر مرجع انتشار پذیرفته نمی‌شود.

    سپس پذیرش بستهٔ پس از انتشار را برای بستهٔ منتشرشدهٔ openclaw@YYYY.M.PATCH-beta.N یا openclaw@beta اجرا کنید. اگر یک پیش‌انتشار ارسال‌شده یا منتشرشده به اصلاح نیاز دارد، شمارهٔ پیش‌انتشار منطبق بعدی را ایجاد کنید؛ هرگز مورد قدیمی را حذف یا بازنویسی نکنید.

  10. در یک تلاش انتشار ناموفق، SHA انتشار را بدون تغییر نگه دارید، مگر اینکه شکست وجود نقصی در محصول یا تغییرات‌نامه را ثابت کند. فرزندان و آرتیفکت‌های تغییرناپذیر موفق را از سر بگیرید؛ هرگز نسخه‌ای از بسته را که قبلاً موفق شده است دوباره نسازید یا منتشر نکنید.

  11. برای انتشار پایدار، فقط پس از آن ادامه دهید که نسخهٔ بتای بررسی‌شده یا نامزد انتشار، مدارک اعتبارسنجی لازم را داشته باشد. انتشار پایدار npm نیز از OpenClaw Release Publish عبور می‌کند و آرتیفکت پیش‌پرواز موفق را از طریق preflight_run_id دوباره به‌کار می‌گیرد. آمادگی انتشار پایدار macOS همچنین به .zip، .dmg، .dSYM.zip بسته‌بندی‌شده و appcast.xml به‌روزشده روی main نیاز دارد؛ گردش‌کار انتشار macOS پس از تأیید آرتیفکت‌های انتشار، appcast امضاشده را به‌طور خودکار در main عمومی منتشر می‌کند، یا اگر حفاظت شاخه ارسال مستقیم را مسدود کند یک PR برای appcast باز یا به‌روزرسانی می‌کند. آمادگی پایدار Windows Hub به آرتیفکت‌های امضاشدهٔ OpenClawCompanion-Setup-x64.exe، OpenClawCompanion-Setup-arm64.exe و OpenClawCompanion-SHA256SUMS.txt در انتشار GitHub مربوط به OpenClaw نیاز دارد. تگ انتشار امضاشدهٔ دقیق openclaw/openclaw-windows-node را به‌عنوان windows_node_tag و نگاشت چکیدهٔ نصب‌کنندهٔ تأییدشده توسط نامزد آن را به‌عنوان windows_node_installer_digests ارسال کنید؛ OpenClaw Release Publish پیش‌نویس انتشار را نگه می‌دارد، Windows Node Release را ارسال می‌کند و هر سه آرتیفکت را پیش از انتشار تأیید می‌کند.

  12. پس از انتشار، تأییدکنندهٔ پس از انتشار npm، در صورت نیاز به مدرک کانال پس از انتشار E2E مستقل و اختیاری Telegram برای npm منتشرشده، ارتقای dist-tag در صورت نیاز، تأیید صفحهٔ تولیدشدهٔ انتشار GitHub و مراحل اعلام انتشار را اجرا کنید؛ سپس پیش از اعلام اتمام انتشار پایدار، نهایی‌سازی main پایدار را تکمیل کنید.

نهایی‌سازی main پایدار

انتشار پایدار تا زمانی که main وضعیت واقعی انتشار عرضه‌شده را دربر نگیرد، کامل نیست.

  1. از تازه‌ترین main شروع کنید. release/YYYY.M.PATCH را در برابر آن ممیزی کنید و اصلاحات واقعیِ موجودنبودن در main را به جلو منتقل کنید. سازگارکننده‌های ویژهٔ انتشار برای سازگاری، آزمون یا اعتبارسنجی را کورکورانه در main جدیدتر ادغام نکنید.
  2. برای مسیر عادی، main را روی نسخهٔ پایدار عرضه‌شده تنظیم کنید. نهایی‌سازی دیرهنگام می‌تواند پس از پیشروی آن به CalVer پایدار بعدی OpenClaw از main استفاده کند؛ صرفاً برای بستن انتشار قبلی، قطار انتشاری را که از قبل شروع شده است به نسخهٔ پایین‌تر برنگردانید. اعتبارسنج همچنان بخش دقیق تغییرات‌نامهٔ عرضه‌شده و ورودی appcast را الزامی می‌داند و نسخه و SHA واقعی main را ثبت می‌کند. پس از هر تغییر نسخهٔ ریشه، pnpm release:prep و سپس pnpm deps:shrinkwrap:generate را اجرا کنید.
  3. بخش ## YYYY.M.PATCH در CHANGELOG.md روی main را دقیقاً با شاخهٔ انتشار تگ‌شده منطبق کنید. اگر انتشار mac یک به‌روزرسانی منتشر کرده است، به‌روزرسانی پایدار appcast.xml را نیز دربر بگیرید.
  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 روز همچنان نهایی‌سازی دستی مبتنی بر مدرک را مسدود می‌کند. فرمان‌های بازیابی خصوصی در راهنمای ویژهٔ نگه‌دارندگان باقی می‌مانند. ارسال دستی را فقط برای تعمیر یا بازپخش نهایی‌سازی پایدار مبتنی بر مدرک به‌کار ببرید.

اگر والد انتشار تنها پس از پیوست‌شدن مدارک تغییرناپذیر npm/Plugin شکست خورد، ابتدا همهٔ آرتیفکت‌های پلتفرم پایدار را تعمیر و منتشر کنید. سپس یک نگه‌دارنده می‌تواند نهایی‌سازی را به‌صورت دستی با allow_failed_publish_recovery=true ارسال کند؛ این حالت فقط یک والد ناموفقِ تکمیل‌شده را می‌پذیرد و علاوه بر آن به قراردادهای دقیق آرتیفکت Android و Windows، چکیده‌های SHA-256 مربوط به GitHub، تأیید جمع مقابله‌ای، منشأ Android و یک ارتقای موفق Windows ارسال‌شده توسط والد نیاز دارد که بررسی‌های Authenticode و چکیده‌های تأییدشده توسط نامزد آن با نصب‌کننده‌های منتشرشده منطبق باشند، در کنار بررسی‌های عادی macOS/appcast. نهایی‌سازی خودکار مبتنی بر ارسال هرگز این حالت بازیابی را فعال نمی‌کند.

یک تگ اصلاحی قدیمیِ بازگشت می‌تواند فقط زمانی مدارک بستهٔ پایه را دوباره به‌کار گیرد که تگ اصلاحی به همان کامیت منبع تگ پایدار پایه حل شود. انتشار Android آن APK تأییدشدهٔ تگ پایه را دوباره به‌کار می‌گیرد و منشأ مربوط به تگ اصلاحی را اضافه می‌کند. اصلاحی با منبع متفاوت باید مدارک بستهٔ خودش را منتشر و تأیید کند و از versionCode بالاتری برای Android استفاده کند.

پیش‌پرواز انتشار

  • پیش از پیش‌پرواز انتشار، pnpm check:test-types را اجرا کنید تا TypeScript آزمون خارج از دروازهٔ محلی و سریع‌تر pnpm check همچنان پوشش داده شود.

  • پیش از پیش‌پرواز انتشار، pnpm check:architecture را اجرا کنید تا بررسی‌های گسترده‌تر چرخهٔ import و مرز معماری خارج از دروازهٔ محلی سریع‌تر سبز باشند.

  • پیش از pnpm release:check، pnpm build && pnpm ui:build را اجرا کنید تا آرتیفکت‌های انتشار موردانتظار dist/* و بستهٔ Control UI برای مرحلهٔ اعتبارسنجی بسته موجود باشند.

  • پس از افزایش نسخهٔ ریشه و پیش از تگ‌گذاری، pnpm release:prep را اجرا کنید. این فرمان همهٔ تولیدکننده‌های قطعی انتشار را که معمولاً پس از تغییر نسخه/پیکربندی/API دچار واگرایی می‌شوند اجرا می‌کند: نسخه‌های Plugin، shrinkwrapهای npm، موجودی Plugin، طرح‌وارهٔ پیکربندی پایه، فرادادهٔ پیکربندی کانال‌های بسته‌بندی‌شده، خط مبنای مستندات پیکربندی، exportهای SDK مربوط به Plugin، مانیفست قرارداد API مربوط به SDK مربوط به Plugin و بسته‌های زبان Control UI. همچنین تا زمانی مسدود می‌ماند که ترجمه‌های برنامه‌های بومی و منابع زبان تولیدشدهٔ پلتفرم با موجودی منبع منطبق شوند؛ اگر عقب هستند، پیش از تثبیت SHA کد منتظر Native App Locale Refresh بمانید یا آن را ارسال کنید. pnpm release:check آن محافظ‌ها را در حالت بررسی دوباره اجرا می‌کند (از جمله دروازه‌های سخت‌گیرانهٔ زبان به‌همراه بودجهٔ سطح SDK مربوط به Plugin) و پیش از اجرای بررسی‌های انتشار بسته، همهٔ شکست‌های واگرایی تولیدشده را در یک گذر گزارش می‌دهد.

  • همگام‌سازی نسخهٔ Plugin به‌طور پیش‌فرض بستهٔ زمان‌اجرای قابل‌انتشار @openclaw/ai، نسخه‌های بستهٔ Pluginهای رسمی و کف‌های موجود openclaw.compat.pluginApi را به نسخهٔ انتشار OpenClaw به‌روزرسانی می‌کند. آن فیلد را کف API مربوط به SDK/زمان‌اجرای Plugin بدانید، نه صرفاً نسخه‌ای کپی‌شده از بسته: برای انتشارهای فقط-Plugin که عمداً با میزبان‌های قدیمی‌تر OpenClaw سازگار می‌مانند، کف را روی قدیمی‌ترین API میزبان پشتیبانی‌شده نگه دارید و این انتخاب را در مدرک انتشار Plugin مستند کنید.

  • گردش‌کار دستی Full Release Validation را پیش از تأیید انتشار اجرا کنید تا همهٔ جعبه‌های آزمون پیش‌انتشار از یک نقطهٔ ورود آغاز شوند. این گردش‌کار یک شاخه، تگ یا SHA کامل کامیت را می‌پذیرد، CI دستی را ارسال می‌کند و OpenClaw Release Checks را برای آزمون دود نصب، پذیرش بسته، بررسی‌های بسته در چند سیستم‌عامل، هم‌ارزی QA Lab، Matrix و مسیرهای Telegram ارسال می‌کند. اجراهای پایدار و کامل همیشه پایش جامع زنده/E2E و مسیر انتشار Docker را دربر می‌گیرند؛ run_release_soak=true برای پایش صریح بتا حفظ شده است. پذیرش بسته، E2E مرجع Telegram برای بسته را هنگام اعتبارسنجی نامزد فراهم می‌کند و از اجرای هم‌زمان نظرسنج زندهٔ دوم جلوگیری می‌کند.

    پس از انتشار بتا، release_package_spec را ارائه کنید تا بستهٔ npm عرضه‌شده در بررسی‌های انتشار، پذیرش بسته و E2E بستهٔ Telegram بدون ساخت دوبارهٔ tarball انتشار استفاده شود. npm_telegram_package_spec را فقط وقتی ارائه کنید که Telegram باید از بستهٔ منتشرشده‌ای متفاوت با بقیهٔ اعتبارسنجی انتشار استفاده کند. package_acceptance_package_spec را وقتی ارائه کنید که پذیرش بسته باید از بستهٔ منتشرشده‌ای متفاوت با مشخصات بستهٔ انتشار استفاده کند. evidence_package_spec را وقتی ارائه کنید که گزارش مدارک انتشار باید بدون اجبار E2E مربوط به Telegram ثابت کند اعتبارسنجی با بستهٔ منتشرشدهٔ npm منطبق است.

    bash
    node scripts/full-release-validation-at-sha.mjs \  --sha <code-sha> \  --target-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_mode=mock-openai یا telegram_mode=live-frontier، QA مربوط به Telegram را روی همان tarball اجرا کند. هنگامی‌که مسیرهای 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: مسیرهای بومی آرتیفکت برای بسته/به‌روزرسانی/راه‌اندازی مجدد/Plugin، بدون OpenWebUI یا ClawHub زنده
    • product: پروفایل بسته به‌همراه کانال‌های MCP، پاک‌سازی cron/زیرعامل، جست‌وجوی وب OpenAI و OpenWebUI
    • full: بخش‌های مسیر انتشار Docker به‌همراه OpenWebUI
    • custom: انتخاب دقیق docker_lanes برای اجرای مجدد متمرکز

  • هنگامی‌که فقط به پوشش عادی و قطعی CI برای نامزد انتشار نیاز دارید، گردش‌کار دستی CI را مستقیماً اجرا کنید. اجراهای دستی CI محدوده‌بندی تغییرات را دور می‌زنند و شاردهای Linux Node، شاردهای Pluginهای همراه، شاردهای قرارداد Plugin و کانال، سازگاری Node 22، check-*، check-additional-*، بررسی‌های دود آرتیفکت ساخته‌شده، بررسی‌های مستندات، Skills پایتون، Windows، macOS و مسیرهای i18n رابط کاربری Control را اجباری می‌کنند. اجراهای دستی و مستقل 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 عبور می‌دهد.

  • هنگام اعتبارسنجی واکشی محافظت‌شدهٔ Prometheus، pnpm qa:prometheus:smoke را اجرا کنید. این مورد QA-lab را آزمایش می‌کند، واکشی‌های احراز هویت‌نشده را رد می‌کند و تأیید می‌کند که خانواده‌های معیار حیاتی برای انتشار، عاری از محتوای پرامپت، شناسه‌های خام، توکن‌های احراز هویت و مسیرهای محلی باقی می‌مانند.

  • برای اجرای پشت‌سرهم مسیرهای دود OpenTelemetry و Prometheus در وارسی منبع، pnpm qa:observability:smoke را اجرا کنید.

  • پیش از هر انتشار تگ‌گذاری‌شده، pnpm release:check را اجرا کنید.

  • پیش‌بررسی OpenClaw NPM Release پیش از بسته‌بندی tarball مربوط به npm، شواهد انتشار وابستگی‌ها را تولید می‌کند. دروازهٔ آسیب‌پذیری هشدارهای npm مانع انتشار است. گزارش‌های ریسک مانیفست گذرا، مالکیت وابستگی/سطح نصب و تغییرات وابستگی فقط شواهد انتشار هستند. گزارش تغییرات وابستگی، نامزد انتشار را با تگ انتشار قابل‌دسترسی قبلی مقایسه می‌کند. پیش‌بررسی شواهد وابستگی را با نام openclaw-release-dependency-evidence-<tag> بارگذاری می‌کند و همچنین آن را در آرتیفکت آماده‌شدهٔ پیش‌بررسی npm، زیر dependency-evidence/، می‌گنجاند. مسیر واقعی انتشار همان آرتیفکت پیش‌بررسی را دوباره به‌کار می‌گیرد و سپس همان شواهد را با نام openclaw-<version>-dependency-evidence.zip به انتشار GitHub پیوست می‌کند.

  • پس از ایجاد تگ، برای توالی انتشار تغییردهنده OpenClaw Release Publish را اجرا کنید. انتشارهای عادی بتا و پایدار را از main مورداعتماد راه‌اندازی کنید؛ تگ انتشار همچنان کامیت هدف دقیق را انتخاب می‌کند و ممکن است به release/YYYY.M.PATCH اشاره کند. انتشارهای آلفای Tideclaw در شاخهٔ آلفای متناظر خود باقی می‌مانند. preflight_run_id موفق npm مربوط به OpenClaw، full_release_validation_run_id موفق و full_release_validation_run_attempt دقیق را ارسال کنید و محدودهٔ پیش‌فرض انتشار Plugin یعنی all-publishable را حفظ کنید، مگر آنکه عمداً در حال اجرای ترمیمی متمرکز باشید. این گردش‌کار انتشار npm مربوط به Plugin، انتشار ClawHub مربوط به Plugin و انتشار npm مربوط به OpenClaw را به‌صورت ترتیبی اجرا می‌کند تا بستهٔ هسته پیش از Pluginهای خارجی‌شدهٔ آن منتشر نشود؛ ارتقای Windows و Android هم‌زمان با انتشار npm هسته و در برابر صفحهٔ پیش‌نویس انتشار اجرا می‌شود. اجرای مجدد انتشار قابل‌ازسرگیری است: اگر نسخهٔ npm هسته از قبل منتشر شده باشد، پس از آنکه گردش‌کار ثابت کند tarball رجیستری با آرتیفکت پیش‌بررسی تگ مطابقت دارد، اجرای هسته نادیده گرفته می‌شود؛ همچنین هنگامی‌که انتشار از قبل قرارداد تأییدشدهٔ آرتیفکت را داشته باشد، ارتقای Windows/Android نادیده گرفته می‌شود تا تلاش مجدد فقط مراحل ناموفق را تکرار کند. ترمیم‌های متمرکز و مختص Plugin به plugin_publish_scope=selected و فهرست غیرخالی Pluginها نیاز دارند. اجراهای all-publishable مختص Plugin به شواهد کامل و تغییرناپذیر پیش‌بررسی و اعتبارسنجی کامل انتشار نیاز دارند؛ شواهد ناقص رد می‌شوند.

  • OpenClaw Release Publish پایدار پس از وجود انتشار غیرپیش‌انتشار متناظر openclaw/openclaw-windows-node، به windows_node_tag دقیق و همچنین نگاشت تأییدشدهٔ نامزد windows_node_installer_digests نیاز دارد. پیش از راه‌اندازی هر فرزند انتشار، تأیید می‌کند که انتشار منبع منتشرشده و غیرپیش‌انتشار است، نصب‌کننده‌های الزامی x64/ARM64 را در بر دارد و همچنان با نگاشت تأییدشده مطابقت دارد. سپس درحالی‌که انتشار OpenClaw هنوز پیش‌نویس است، Windows Node Release را راه‌اندازی می‌کند و نگاشت تثبیت‌شدهٔ چکیدهٔ نصب‌کننده را بدون تغییر منتقل می‌کند. گردش‌کار فرزند، نصب‌کننده‌های امضاشدهٔ Windows Hub را از همان تگ دقیق دریافت می‌کند، آن‌ها را با چکیده‌های تثبیت‌شده تطبیق می‌دهد، روی یک اجراکنندهٔ Windows تأیید می‌کند که امضاهای Authenticode آن‌ها از امضاکنندهٔ موردانتظار OpenClaw Foundation استفاده می‌کنند، یک مانیفست SHA-256 می‌نویسد و نصب‌کننده‌ها را به‌همراه مانیفست در انتشار مرجع GitHub مربوط به OpenClaw بارگذاری می‌کند؛ سپس آرتیفکت‌های ارتقایافته را دوباره دریافت می‌کند و عضویت در مانیفست و هش‌ها را تأیید می‌کند. والد پیش از انتشار، قرارداد فعلی آرتیفکت‌های x64، ARM64 و مجموع مقابله‌ای را تأیید می‌کند. بازیابی مستقیم پیش از جایگزینی آرتیفکت‌های موردانتظار قرارداد با بایت‌های منبع تثبیت‌شده، نام‌های غیرمنتظرهٔ آرتیفکت OpenClawCompanion-* را رد می‌کند.

    Windows Node Release را فقط برای بازیابی به‌صورت دستی راه‌اندازی کنید و همیشه یک تگ دقیق، هرگز latest، را به‌همراه نگاشت JSON صریح expected_installer_digests از انتشار منبع تأییدشده ارسال کنید. پیوندهای دانلود وب‌سایت باید URLهای دقیق آرتیفکت انتشار OpenClaw برای انتشار پایدار فعلی را هدف بگیرند، یا فقط پس از تأیید اینکه تغییرمسیر latest در GitHub به همان انتشار اشاره می‌کند از releases/latest/download/... استفاده کنند؛ فقط به صفحهٔ انتشار مخزن همراه پیوند ندهید.

  • بررسی‌های انتشار اکنون در یک گردش‌کار دستی جداگانه اجرا می‌شوند: OpenClaw Release Checks. این گردش‌کار همچنین پیش از تأیید انتشار، مسیر برابری ماک QA Lab، نمایه انتشار Matrix و مسیر QA مربوط به Telegram را اجرا می‌کند. مسیرهای زنده از محیط qa-live-shared استفاده می‌کنند؛ Telegram همچنین از اجاره اعتبارنامه‌های Convex CI استفاده می‌کند. هنگامی که همه سناریوهای نگه‌داری‌شده Matrix را می‌خواهید، گردش‌کار دستی QA-Lab - All Lanes را با matrix_profile=all اجرا کنید؛ گردش‌کار این انتخاب را میان نمایه‌های انتقال، رسانه و E2EE توزیع می‌کند تا اثبات کامل در محدوده مهلت زمانی هر job باقی بماند.

  • اعتبارسنجی زمان اجرای نصب و ارتقا در سیستم‌عامل‌های مختلف بخشی از OpenClaw Release Checks و Full Release Validation عمومی است که گردش‌کار قابل‌استفاده‌مجدد .github/workflows/openclaw-cross-os-release-checks-reusable.yml را مستقیماً فراخوانی می‌کنند. این جداسازی عمدی است: مسیر واقعی انتشار npm را کوتاه، قطعی و متمرکز بر artifact نگه می‌دارد، درحالی‌که بررسی‌های زنده کندتر در مسیر خود باقی می‌مانند تا انتشار را متوقف یا مسدود نکنند.

  • بررسی‌های انتشار حاوی secret باید از طریق Full Release Validation یا از ref گردش‌کار main/release اعزام شوند تا منطق گردش‌کار و secretها تحت کنترل باقی بمانند.

  • OpenClaw Release Checks یک شاخه، tag یا SHA کامل commit را می‌پذیرد، مشروط بر اینکه commit حل‌شده از یک شاخه یا tag انتشار OpenClaw قابل‌دسترسی باشد.

  • پیش‌بررسی صرفاً اعتبارسنجی OpenClaw NPM Release نیز SHA کامل 40 نویسه‌ای commit فعلی شاخه گردش‌کار را بدون نیاز به tag پوش‌شده می‌پذیرد. این مسیر SHA فقط برای اعتبارسنجی است و نمی‌توان آن را به انتشار واقعی ارتقا داد. در حالت SHA، گردش‌کار v<package.json version> را فقط برای بررسی فراداده بسته ایجاد می‌کند؛ انتشار واقعی همچنان به یک tag انتشار واقعی نیاز دارد.

  • هر دو گردش‌کار، مسیر انتشار و ارتقای واقعی را روی runnerهای میزبانی‌شده GitHub نگه می‌دارند، درحالی‌که مسیر اعتبارسنجی بدون تغییر می‌تواند از runnerهای بزرگ‌تر Blacksmith Linux استفاده کند.

  • آن گردش‌کار OPENCLAW_LIVE_TEST=1 OPENCLAW_LIVE_CACHE_TEST=1 pnpm test:live:cache را با استفاده از هر دو secret گردش‌کار OPENAI_API_KEY و ANTHROPIC_API_KEY اجرا می‌کند.

  • پیش‌بررسی انتشار npm دیگر منتظر مسیر جداگانه بررسی‌های انتشار نمی‌ماند.

  • پیش از tag کردن محلی یک نامزد انتشار، RELEASE_TAG=vYYYY.M.PATCH-beta.N pnpm release:fast-pretag-check را اجرا کنید. این ابزار کمکی محافظ‌های سریع انتشار، بررسی‌های انتشار npm/ClawHub مربوط به plugin، build، build رابط کاربری و release:openclaw:npm:check را به ترتیبی اجرا می‌کند که خطاهای رایج مسدودکننده تأیید را پیش از شروع گردش‌کار انتشار GitHub تشخیص دهد.

  • پیش از تأیید، RELEASE_TAG=vYYYY.M.PATCH node --import tsx scripts/openclaw-npm-release-check.ts (یا tag پیش‌انتشار/اصلاحی متناظر) را اجرا کنید.

  • پس از انتشار 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 و E2E واقعی Telegram در برابر بسته منتشرشده npm با استفاده از مخزن مشترک اجاره‌ای اعتبارنامه Telegram اعتبارسنجی شوند. برای اجراهای موردی محلی نگه‌دارندگان می‌توان متغیرهای Convex را حذف کرد و سه اعتبارنامه محیطی OPENCLAW_QA_TELEGRAM_* را مستقیماً ارائه داد.

  • برای اجرای آزمون دود کامل بتا پس از انتشار از دستگاه یک نگه‌دارنده، از pnpm release:beta-smoke -- --beta betaN استفاده کنید. این ابزار کمکی اعتبارسنجی به‌روزرسانی npm و هدف تازه Parallels را اجرا می‌کند، NPM Telegram Beta E2E را اعزام می‌کند، اجرای دقیق گردش‌کار را پایش می‌کند، artifact را بارگیری می‌کند و گزارش Telegram را چاپ می‌کند.

  • نگه‌دارندگان می‌توانند همان بررسی پس از انتشار را از GitHub Actions و از طریق گردش‌کار دستی NPM Telegram Beta E2E اجرا کنند. این گردش‌کار عمداً فقط دستی است و در هر merge اجرا نمی‌شود.

  • خودکارسازی انتشار نگه‌دارندگان از الگوی پیش‌بررسی-سپس-ارتقا استفاده می‌کند:

    • انتشار واقعی npm باید یک preflight_run_id موفق npm را پشت سر بگذارد.
    • هماهنگ‌سازی انتشار و پیش‌بررسی معمول بتا و پایدار، main مورداعتماد را در برابر tag هدف دقیق به‌کار می‌گیرد. انتشار و پیش‌بررسی آلفای Tideclaw از شاخه آلفای متناظر استفاده می‌کند.
    • انتشارهای پایدار npm به‌طور پیش‌فرض از beta استفاده می‌کنند؛ انتشار پایدار npm می‌تواند از طریق ورودی گردش‌کار صراحتاً latest را هدف بگیرد.
    • تغییر dist-tag مبتنی بر token در npm در openclaw/releases/.github/workflows/openclaw-npm-dist-tags.yml قرار دارد، زیرا npm dist-tag add همچنان به NPM_TOKEN نیاز دارد، درحالی‌که مخزن منبع انتشار را فقط مبتنی بر OIDC نگه می‌دارد.
    • macOS Release عمومی فقط برای اعتبارسنجی است؛ هنگامی که یک tag فقط روی شاخه انتشار قرار دارد اما گردش‌کار از main اعزام می‌شود، public_release_branch=release/YYYY.M.PATCH را تنظیم کنید.
    • انتشار واقعی macOS باید preflight_run_id و validate_run_id موفق macOS را پشت سر بگذارد.
    • مسیرهای انتشار واقعی به‌جای build مجدد، artifactهای آماده‌شده را ارتقا می‌دهند.

  • برای انتشارهای اصلاحی پایدار مانند YYYY.M.PATCH-N، اعتبارسنج پس از انتشار همان مسیر ارتقای پیشوند موقت از YYYY.M.PATCH به YYYY.M.PATCH-N را نیز بررسی می‌کند تا اصلاحات انتشار نتوانند نصب‌های سراسری قدیمی‌تر را بی‌سروصدا روی محتوای پایه پایدار باقی بگذارند.

  • پیش‌بررسی انتشار npm به‌صورت بسته ناموفق می‌شود، مگر اینکه tarball هم dist/control-ui/index.html و هم محتوای غیرخالی dist/control-ui/assets/ را در بر داشته باشد تا دوباره داشبورد مرورگر خالی منتشر نکنیم.

  • اعتبارسنجی پس از انتشار همچنین بررسی می‌کند که entrypointهای plugin منتشرشده و فراداده بسته در چیدمان رجیستری نصب‌شده موجود باشند. انتشاری که محتوای زمان اجرای plugin را نداشته باشد، در اعتبارسنج پس از انتشار ناموفق می‌شود و نمی‌تواند به latest ارتقا یابد.

  • pnpm test:install:smoke همچنین بودجه unpackedSize مربوط به npm pack را روی tarball به‌روزرسانی نامزد اعمال می‌کند تا e2e نصب‌کننده افزایش ناخواسته حجم بسته را پیش از مسیر انتشار تشخیص دهد.

  • اگر کار انتشار برنامه‌ریزی CI، manifestهای زمان‌بندی افزونه یا ماتریس‌های آزمون افزونه را تغییر داده است، پیش از تأیید، خروجی‌های ماتریس plugin-prerelease-extension-shard تحت مالکیت برنامه‌ریز را از .github/workflows/plugin-prerelease.yml بازتولید و بازبینی کنید تا یادداشت‌های انتشار یک چیدمان قدیمی CI را توصیف نکنند.

  • آمادگی انتشار پایدار macOS سطوح به‌روزرسان را نیز شامل می‌شود: انتشار GitHub باید در نهایت شامل .zip، .dmg و .dSYM.zip بسته‌بندی‌شده باشد؛ appcast.xml در main باید پس از انتشار به zip پایدار جدید اشاره کند (گردش‌کار انتشار macOS آن را به‌طور خودکار commit می‌کند، یا هنگامی که push مستقیم مسدود باشد یک PR برای appcast باز می‌کند)؛ برنامه بسته‌بندی‌شده باید شناسه bundle غیر debug، نشانی feed غیرخالی Sparkle و CFBundleVersion برابر یا بالاتر از حداقل build معیار Sparkle برای آن نسخه انتشار را حفظ کند.

جعبه‌های آزمون انتشار

Full Release Validation روشی است که اپراتورها ماتریس کامل محصول را از یک entrypoint آغاز می‌کنند. از ابزار کمکی استفاده کنید تا هر گردش‌کار فرزند از یک شاخه موقت ثابت‌شده روی یک SHA مورداعتماد گردش‌کار main اجرا شود، درحالی‌که commit درخواستی همچنان نامزد تحت آزمون باقی می‌ماند:

bash
pnpm ci:full-release \  --sha <code-sha> \  --target-ref release/YYYY.M.PATCH

ابزار کمکی origin/main فعلی را fetch می‌کند، release-ci/<workflow-sha>-... را در آن commit مورداعتماد گردش‌کار push می‌کند، برای نسخه‌های بسته آلفا/بتا beta و در غیر این صورت stable را استنباط می‌کند، Full Release Validation را با ref=<target-sha> از شاخه موقت اعزام می‌کند، تأیید می‌کند که headSha هر گردش‌کار فرزند با SHA سنجاق‌شده گردش‌کار والد مطابقت دارد و سپس شاخه موقت را حذف می‌کند. برای اجبار یک اجرای تازه، -f reuse_evidence=false، برای بررسی گسترده مشورتی، -f release_profile=full، یا برای سنجاق کردن commit قدیمی‌تری که همچنان از origin/main فعلی قابل‌دسترسی است، --workflow-sha <trusted-main-sha> را ارائه دهید. خود گردش‌کار هرگز refهای مخزن را نمی‌نویسد. این کار ابزار انتشار مخصوص main را بدون افزودن commitهای ابزار به نامزد در دسترس نگه می‌دارد و از اثبات تصادفی اجرای فرزند جدیدتر main جلوگیری می‌کند.

پس از سبز شدن SHA کد، فقط CHANGELOG.md را commit کنید و همان ابزار کمکی را با SHA انتشار اجرا کنید:

bash
pnpm ci:full-release \  --sha <release-sha> \  --target-ref release/YYYY.M.PATCH

والد دوم فقط هنگامی از شواهد محصول دوباره استفاده می‌کند که GitHub ثابت کند SHA انتشار از SHA کد منشعب شده و مجموعه کامل مسیرهای تغییرکرده دقیقاً CHANGELOG.md است. این والد changelog-only-release-v1 را ثبت می‌کند و هیچ فرزند محصولی را اعزام نمی‌کند. پیش‌بررسی npm و پذیرش بسته/نصب همچنان روی SHA انتشار اجرا می‌شوند، زیرا بایت‌های tarball آن تغییر کرده‌اند.

برای یک SHA کد تازه، گردش‌کار هدف را حل می‌کند، CI دستی را اعزام می‌کند و سپس OpenClaw Release Checks را اعزام می‌کند. OpenClaw Release Checks آزمون دود نصب، بررسی‌های انتشار در سیستم‌عامل‌های مختلف، پوشش زنده/E2E مسیر انتشار Docker در صورت فعال بودن soak، پذیرش بسته با E2E معیار بسته Telegram، برابری QA Lab، Matrix زنده و Telegram زنده را توزیع می‌کند. اجرای full/all فقط هنگامی قابل‌قبول است که خلاصه Full Release Validation، normal_ci، plugin_prerelease و release_checks را موفق نشان دهد، مگر اینکه اجرای مجدد متمرکز عمداً فرزند جداگانه Plugin Prerelease را رد کرده باشد. از فرزند مستقل npm-telegram فقط برای اجرای مجدد متمرکز بسته منتشرشده با release_package_spec یا npm_telegram_package_spec استفاده کنید. خلاصه نهایی اعتبارسنج شامل جدول‌های کندترین job برای هر اجرای فرزند است تا مدیر انتشار بتواند مسیر بحرانی فعلی را بدون بارگیری logها ببیند.

فرزند عملکرد محصول در این مسیر انتشار فقط artifact تولید می‌کند. گردش‌کار چتری آن را با publish_reports=false اعزام می‌کند و اعتبارسنجی رد می‌شود، مگر اینکه محافظ صرفاً artifact آن ثابت کند ناشر گزارش Clawgrit همچنان رد شده است.

برای ماتریس کامل مراحل، نام دقیق jobهای گردش‌کار، تفاوت نمایه‌های پایدار و کامل، artifactها و کنترل‌های اجرای مجدد متمرکز، به اعتبارسنجی کامل انتشار مراجعه کنید.

گردش‌کارهای فرزند از ref مورداعتماد سنجاق‌شده به SHA که Full Release Validation را اجرا می‌کند اعزام می‌شوند. هر اجرای فرزند باید از SHA دقیق گردش‌کار والد استفاده کند. برای اثبات انتشار از اعزام‌های خام --ref main -f ref=<sha> استفاده نکنید؛ از pnpm ci:full-release --sha <target-sha> --target-ref release/YYYY.M.PATCH استفاده کنید.

برای انتخاب گستره زنده/provider از release_profile استفاده کنید:

  • beta: سریع‌ترین مسیر حیاتی انتشار برای مسیر زنده و Docker مربوط به OpenAI/core
  • stable: پوشش provider/backend بتا به‌علاوه پایدار برای تأیید انتشار
  • full: پوشش پایدار به‌علاوه گسترده مشورتی provider/رسانه

اعتبارسنجی پایدار و کامل همیشه پیش از ارتقا، بررسی جامع زنده/E2E، مسیر انتشار Docker و بازماندن ارتقای منتشرشده محدود را اجرا می‌کند. برای درخواست همان بررسی برای یک بتا، از run_release_soak=true استفاده کنید. این بررسی چهار بسته پایدار اخیر، به‌علاوه مبناهای سنجاق‌شده 2026.4.23 و 2026.5.2 و نیز پوشش قدیمی‌تر 2026.4.15 را در بر می‌گیرد؛ مبناهای تکراری حذف می‌شوند و هر مبنا در job مستقل runner مربوط به Docker توزیع می‌شود.

OpenClaw Release Checks از ref مورداعتماد گردش‌کار استفاده می‌کند تا ref هدف را یک‌بار به‌صورت release-package-under-test حل کند و هنگام اجرای soak همان artifact را در بررسی‌های سیستم‌عامل‌های مختلف، پذیرش بسته و Docker مسیر انتشار دوباره به‌کار گیرد. این کار همه جعبه‌های مرتبط با بسته را روی بایت‌های یکسان نگه می‌دارد و از buildهای تکراری بسته جلوگیری می‌کند. پس از اینکه یک بتا از قبل روی npm قرار گرفت، release_package_spec=openclaw@YYYY.M.PATCH-beta.N را تنظیم کنید تا بررسی‌های انتشار بسته عرضه‌شده را یک‌بار بارگیری کنند، SHA منبع build آن را از dist/build-info.json استخراج کنند و همان artifact را برای مسیرهای سیستم‌عامل‌های مختلف، پذیرش بسته، Docker مسیر انتشار و Telegram بسته دوباره به‌کار گیرند.

آزمون دود نصب OpenAI در سیستم‌عامل‌های مختلف، در صورت تنظیم بودن متغیر مخزن/سازمان از OPENCLAW_CROSS_OS_OPENAI_MODEL و در غیر این صورت از openai/gpt-5.6-luna استفاده می‌کند، زیرا این مسیر در حال اثبات نصب بسته، راه‌اندازی اولیه، شروع Gateway و یک نوبت زنده agent است، نه سنجش عملکرد توانمندترین مدل. ماتریس گسترده‌تر provider زنده همچنان محل پوشش ویژه مدل است.

بسته به مرحله انتشار، از این گونه‌ها استفاده کنید:

bash
# اعتبارسنجی Code SHA کامل محصول.pnpm ci:full-release \  --sha <code-sha> \  --target-ref release/YYYY.M.PATCH # اعتبارسنجی Release SHA صرفاً شامل تغییرنامه با استفادهٔ مجدد از شواهد محصول Code SHA.pnpm ci:full-release \  --sha <release-sha> \  --target-ref release/YYYY.M.PATCH # پس از انتشار نسخهٔ بتا، E2E مربوط به Telegram را برای بستهٔ منتشرشده اضافه کنید.pnpm ci:full-release \  --sha <release-sha> \  --target-ref release/YYYY.M.PATCH \  -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

پس از یک اصلاح متمرکز، در نخستین اجرای مجدد از چتر کامل استفاده نکنید. اگر یک باکس شکست خورد، برای اثبات بعدی از گردش‌کار فرزند، job، مسیر Docker، پروفایل بسته، ارائه‌دهندهٔ مدل یا مسیر QA شکست‌خورده استفاده کنید. چتر کامل را فقط هنگامی دوباره اجرا کنید که اصلاح، هماهنگ‌سازی مشترک انتشار را تغییر داده یا شواهد قبلی همهٔ باکس‌ها را منسوخ کرده باشد. اعتبارسنج نهایی چتر، شناسه‌های ثبت‌شدهٔ اجرای گردش‌کارهای فرزند را دوباره بررسی می‌کند؛ بنابراین پس از اجرای مجدد موفق یک گردش‌کار فرزند، فقط job والد شکست‌خوردهٔ Verify full validation را دوباره اجرا کنید.

rerun_group=all می‌تواند از اجرای سبز قبلی چتر دوباره استفاده کند، مشروط بر اینکه پروفایل انتشار، تنظیم مؤثر soak و ورودی‌های اعتبارسنجی یکسان باشند و SHA هدف یا یکسان باشد، یا هدف جدید یک نواده باشد که مجموعهٔ کامل مسیرهای تغییریافتهٔ آن دقیقاً CHANGELOG.md است. استفادهٔ مجدد از هدف دقیق، exact-target-full-validation-v1 را ثبت می‌کند؛ Release SHA پس از اعتبارسنجی، changelog-only-release-v1 را ثبت می‌کند. مورد دوم فقط از اعتبارسنجی محصول دوباره استفاده می‌کند. پیش‌بررسی Npm، بایت‌های بسته، منشأ یادداشت انتشار و پذیرش نصب/به‌روزرسانی همچنان باید در برابر Release SHA اجرا شوند. هر تغییر در نسخه، منبع، محتوای تولیدشده، وابستگی، بسته یا هدف تحت مالکیت گردش‌کار، به Code SHA جدید و اعتبارسنجی کامل تازه نیاز دارد. اجراهای جدیدتر چتر برای همان ref مربوط به 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 نیاز دارند؛ اجراهای کامل/همه از E2E استاندارد بستهٔ Telegram درون Package Acceptance استفاده می‌کنند. اجراهای مجدد متمرکز میان‌سیستم‌عاملی می‌توانند cross_os_suite_filter=windows/packaged-upgrade یا فیلتر سیستم‌عامل/مجموعهٔ دیگری را اضافه کنند. شکست‌های بررسی انتشار QA، اعتبارسنجی عادی انتشار را مسدود می‌کنند؛ از جمله انحراف ابزار پویای OpenClaw در مسیر جفت زمان‌اجرای هسته. اجراهای آلفای Tideclaw همچنان می‌توانند مسیرهای بررسی انتشار غیرمرتبط با ایمنی بسته را مشورتی تلقی کنند. با release_profile=beta، مجموعه‌های ارائه‌دهندهٔ زندهٔ Run repo/live E2E validation مشورتی هستند (هشدارند، نه مسدودکننده)؛ پروفایل‌های پایدار و کامل همچنان آن‌ها را مسدودکننده نگه می‌دارند. هنگامی که live_suite_filter صراحتاً یک مسیر زندهٔ QA دارای گیت، مانند Discord، WhatsApp یا Slack را درخواست می‌کند، متغیر متناظر مخزن یعنی OPENCLAW_RELEASE_QA_*_LIVE_CI_ENABLED باید فعال باشد؛ در غیر این صورت، ثبت ورودی شکست می‌خورد و مسیر بی‌سروصدا رد نمی‌شود.

Vitest

باکس Vitest همان گردش‌کار فرزند دستی CI است. CI دستی عمداً محدوده‌بندی بر پایهٔ تغییرات را دور می‌زند و گراف آزمون عادی را برای نامزد انتشار اجباری می‌کند: shardهای Linux Node، shardهای Plugin همراه، shardهای قرارداد Plugin و کانال، سازگاری Node 22، check-*، check-additional-*، بررسی‌های دودِ مصنوعات ساخته‌شده، بررسی‌های مستندات، Skills پایتون، Windows، macOS و بومی‌سازی Control UI. هنگامی که Full Release Validation باکس را اجرا می‌کند، Android نیز لحاظ می‌شود، زیرا چتر include_android=true را ارسال می‌کند؛ CI دستی مستقل برای پوشش Android به include_android=true نیاز دارد.

از این باکس برای پاسخ به این پرسش استفاده کنید: «آیا درخت منبع، مجموعه‌آزمون کامل عادی را با موفقیت گذراند؟» این با اعتبارسنجی محصول در مسیر انتشار یکسان نیست. شواهدی که باید نگه دارید:

  • خلاصهٔ Full Release Validation که URL اجرای اعزام‌شدهٔ CI را نشان می‌دهد
  • سبز بودن اجرای CI روی SHA هدف دقیق
  • نام shardهای شکست‌خورده یا کند از jobهای CI هنگام بررسی پس‌رفت‌ها
  • مصنوعات زمان‌بندی Vitest مانند .artifacts/vitest-shard-timings.json هنگامی که یک اجرا به تحلیل عملکرد نیاز دارد

CI دستی را فقط هنگامی مستقیماً اجرا کنید که انتشار به CI عادی قطعی نیاز دارد، اما به باکس‌های Docker، QA Lab، زنده، میان‌سیستم‌عاملی یا بسته نیازی ندارد. برای CI مستقیم بدون Android از فرمان اول استفاده کنید. هنگامی که CI مستقیم نامزد انتشار باید Android را پوشش دهد، include_android=true را اضافه کنید:

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 هدف، با اجرای jobهای بررسی دودِ QR، ریشه/Gateway و نصب‌کننده/Bun به‌صورت shardهای جداگانهٔ بررسی دودِ نصب
  • مسیرهای 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-h و openwebui
  • پوشش OpenWebUI روی اجراکنندهٔ اختصاصی با دیسک بزرگ، در صورت درخواست
  • مسیرهای تفکیک‌شدهٔ نصب/حذف Plugin همراه، از bundled-plugin-install-uninstall-0 تا bundled-plugin-install-uninstall-23
  • مجموعه‌های ارائه‌دهندهٔ زنده/E2E و پوشش مدل زندهٔ Docker، هنگامی که بررسی‌های انتشار شامل مجموعه‌های زنده باشند

پیش از اجرای مجدد، از مصنوعات Docker استفاده کنید. زمان‌بند مسیر انتشار، .artifacts/docker-tests/ را همراه با گزارش‌های مسیر، summary.json، failures.json، زمان‌بندی مرحله‌ها، JSON طرح زمان‌بند و فرمان‌های اجرای مجدد بارگذاری می‌کند. برای بازیابی متمرکز، به‌جای اجرای مجدد همهٔ قطعه‌های انتشار، از docker_lanes=<lane[,lane]> در گردش‌کار قابل‌استفادهٔ مجدد زنده/E2E استفاده کنید. فرمان‌های اجرای مجدد تولیدشده، در صورت موجود بودن، شامل package_artifact_run_id قبلی و ورودی‌های تصویر آماده‌شدهٔ Docker هستند؛ بنابراین یک مسیر شکست‌خورده می‌تواند از همان tarball و تصاویر GHCR دوباره استفاده کند.

QA Lab

باکس QA Lab نیز بخشی از OpenClaw Release Checks است. این باکس گیت انتشار برای رفتار عامل‌محور و سطح کانال است و از سازوکارهای بستهٔ Vitest و Docker جداست.

پوشش QA Lab انتشار شامل موارد زیر است:

  • مسیر برابری ساختگی که مسیر نامزد OpenAI را با خط مبنای anthropic/claude-opus-4-8 و با استفاده از بستهٔ برابری عامل‌محور مقایسه می‌کند
  • پروفایل انتشار آداپتور زندهٔ Matrix با استفاده از محیط qa-live-shared
  • مسیر زندهٔ QA مربوط به Telegram با استفاده از اجاره‌های اعتبارنامهٔ Convex CI
  • pnpm qa:otel:smoke، pnpm qa:otel:collector-smoke، pnpm qa:prometheus:smoke یا pnpm qa:observability:smoke هنگامی که تله‌متری انتشار به اثبات محلی صریح نیاز دارد

از این باکس برای پاسخ به این پرسش استفاده کنید: «آیا انتشار در سناریوهای QA و جریان‌های زندهٔ کانال به‌درستی رفتار می‌کند؟» هنگام تأیید انتشار، URL مصنوعات مسیرهای برابری، Matrix و Telegram را نگه دارید. پوشش کامل Matrix همچنان به‌شکل اجرای دستی shardشدهٔ QA Lab در دسترس است و مسیر پیش‌فرض و حیاتی انتشار نیست.

بسته

باکس Package گیت محصول قابل‌نصب است. پشتیبان آن Package Acceptance و حل‌کنندهٔ scripts/resolve-openclaw-package-candidate.mjs هستند. حل‌کننده یک نامزد را به tarball مربوط به package-under-test که Docker E2E مصرف می‌کند نرمال‌سازی می‌کند، موجودی بسته را اعتبارسنجی می‌کند، نسخهٔ بسته و SHA-256 را ثبت می‌کند و ref مهار گردش‌کار را از ref منبع بسته جدا نگه می‌دارد.

منابع پشتیبانی‌شدهٔ نامزد:

  • source=npm: openclaw@beta، openclaw@latest یا نسخهٔ دقیق انتشار OpenClaw
  • source=ref: بسته‌بندی یک شاخه، برچسب یا SHA کامل commit مورداعتمادِ package_ref با مهار انتخاب‌شدهٔ 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، Package Acceptance را با 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 اجرا می‌کند. Package Acceptance مهاجرت، به‌روزرسانی، ارتقای VPS مدیریت‌شده توسط ریشه، راه‌اندازی مجدد به‌روزرسانی با احراز هویت پیکربندی‌شده، نصب زندهٔ Skill از ClawHub، پاک‌سازی وابستگی‌های منسوخ Plugin، fixtureهای آفلاین Plugin، به‌روزرسانی Plugin، مقاوم‌سازی فرار اتصال فرمان Plugin و QA بستهٔ 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 گسترش می‌دهد. برای نامزدی که از قبل منتشر شده است از Package Acceptance با source=npm، برای tarball محلی npm متکی به SHA پیش از انتشار از source=ref، برای آینهٔ سازمانی/خصوصی تحت مالکیت نگه‌دارنده از source=trusted-url یا برای tarball آماده‌شده‌ای که اجرای دیگری از GitHub Actions بارگذاری کرده است از source=artifact استفاده کنید.

این جایگزین بومی GitHub برای بخش عمدهٔ پوشش بسته/به‌روزرسانی است که پیش‌تر به Parallels نیاز داشت. بررسی‌های انتشار میان‌سیستم‌عاملی همچنان برای راه‌اندازی اولیه، نصب‌کننده و رفتار مختص پلتفرم اهمیت دارند، اما اعتبارسنجی محصول برای بسته/به‌روزرسانی باید Package Acceptance را ترجیح دهد.

چک‌لیست استاندارد اعتبارسنجی به‌روزرسانی و Plugin، آزمودن به‌روزرسانی‌ها و Pluginها است. هنگام تصمیم‌گیری دربارهٔ اینکه کدام مسیر محلی، Docker، Package Acceptance یا بررسی انتشار، تغییر مربوط به نصب/به‌روزرسانی Plugin، پاک‌سازی doctor یا مهاجرت بستهٔ منتشرشده را اثبات می‌کند، از آن استفاده کنید. مهاجرت جامع به‌روزرسانی منتشرشده از همهٔ بسته‌های پایدار 2026.4.23+ یک گردش‌کار دستی جداگانهٔ Update Migration است و بخشی از Full Release CI نیست.

سهل‌گیری قدیمی Package Acceptance عمداً محدود به بازهٔ زمانی مشخصی است. بسته‌ها تا 2026.4.25 می‌توانند برای شکاف‌های فراداده‌ای که از قبل در npm منتشر شده‌اند از مسیر سازگاری استفاده کنند: ورودی‌های موجودی QA خصوصی که در tarball وجود ندارند، نبود gateway install --wrapper، نبود فایل‌های patch در fixture گیت مشتق‌شده از tarball، نبود update.channel ماندگار، مکان‌های قدیمی رکورد نصب Plugin، نبود ماندگاری رکورد نصب marketplace و مهاجرت فرادادهٔ پیکربندی در طول plugins update. بستهٔ منتشرشدهٔ 2026.4.26 ممکن است برای فایل‌های مهر فرادادهٔ ساخت محلی که از قبل منتشر شده‌اند هشدار دهد. بسته‌های بعدی باید قراردادهای مدرن بسته را برآورده کنند؛ همان شکاف‌ها باعث شکست اعتبارسنجی انتشار می‌شوند.

هنگامی که پرسش انتشار دربارهٔ یک بستهٔ واقعاً قابل‌نصب است، از پروفایل‌های گسترده‌تر Package Acceptance استفاده کنید:

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 به‌همراه اثبات زنده نصب مهارت ClawHub؛ این گزینه پیش‌فرض بررسی انتشار است
  • product: package به‌همراه کانال‌های MCP، پاک‌سازی cron/زیرعامل، جست‌وجوی وب OpenAI و OpenWebUI
  • full: بخش‌های مسیر انتشار Docker به‌همراه OpenWebUI
  • custom: فهرست دقیق docker_lanes برای اجرای مجدد متمرکز

برای اثبات Telegram نامزد بسته، telegram_mode=mock-openai یا telegram_mode=live-frontier را در پذیرش بسته فعال کنید. گردش‌کار، tarball حل‌شده package-under-test را به مسیر Telegram منتقل می‌کند؛ گردش‌کار مستقل Telegram همچنان یک مشخصه npm منتشرشده را برای بررسی‌های پس از انتشار می‌پذیرد.

خودکارسازی انتشار عادی

برای انتشار بتا، latest، Plugin، GitHub Release و پلتفرم، OpenClaw Release Publish نقطه ورود عادی تغییردهنده است. مسیر extended-stable ماهانه Gateway در .33+ از این هماهنگ‌کننده استفاده نمی‌کند. گردش‌کار عادی، گردش‌کارهای ناشر مورداعتماد را به‌ترتیب موردنیاز انتشار هماهنگ می‌کند:

  1. تگ انتشار را دریافت و SHA کامیت آن را تعیین کنید.
  2. بررسی کنید که تگ از main یا release/* قابل‌دسترسی باشد (یا برای پیش‌انتشارهای آلفا، از یک شاخه آلفای Tideclaw).
  3. pnpm plugins:sync:check را اجرا کنید.
  4. Plugin NPM Release را با publish_scope=all-publishable و ref=<release-sha> اعزام کنید.
  5. Plugin ClawHub Release را با همان دامنه و SHA اعزام کنید.
  6. پس از تأیید full_release_validation_run_id ذخیره‌شده و تلاش دقیق اجرا، OpenClaw NPM Release را با تگ انتشار، dist-tag مربوط به npm و preflight_run_id ذخیره‌شده اعزام کنید.
  7. برای انتشارهای پایدار، GitHub release را به‌صورت پیش‌نویس ایجاد یا به‌روزرسانی کنید، Windows Node Release را با windows_node_tag صریح و windows_node_installer_digests تأییدشده برای نامزد اعزام کنید و دارایی‌های متعارف نصب‌کننده/checksum ویندوز را بررسی کنید. همچنین Android Release را برای ساخت APK امضاشده تگ دقیق به‌همراه checksum و منشأ اعزام کنید. پیش از انتشار پیش‌نویس، هر دو قرارداد دارایی بومی را بررسی کنید.

نمونه انتشار بتا:

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

انتشار پایدار در dist-tag پیش‌فرض بتا:

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 فقط برای کارهای متمرکز ترمیم یا انتشار مجدد استفاده کنید. هنگامی که publish_openclaw_npm=true، مقدار OpenClaw Release Publish، plugin_publish_scope=selected را رد می‌کند تا بسته اصلی نتواند بدون همه 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 را بارگذاری نمی‌کند، بایت‌های بسته را منتشر نمی‌کند و پیکربندی ناشر مورداعتماد را تغییر نمی‌دهد. گردش‌کار همچنان برنامه زنده رجیستری را تعیین می‌کند، هدف را فقط در یک job بدون secret دریافت و بسته‌بندی می‌کند، زنجیره‌ابزار قفل‌شده ClawHub را آماده می‌سازد و پیش از وجود تگ انتشار، artifact تغییرناپذیر و slug/هویت بسته را اعتبارسنجی می‌کند. محیط clawhub-plugin-bootstrap را فقط پس از پایان jobهای بسته‌بندی بدون secret تأیید کنید؛ این job اعتبارسنجی محافظت‌شده هیچ اعتبارنامه یا فرمان تغییردهنده‌ای ندارد.

اجرای آزمایشی تأییدشده یا راه‌اندازی اولیه واقعی پس از تگ‌گذاری باید شامل تگ دقیق انتشار، شناسه اجرای والد OpenClaw Release Publish، تلاش و شاخه باشد. والد، SHA گردش‌کار خودش و یک SHA دقیق و مجزای مورداعتماد main را برای Plugin ClawHub New گواهی می‌کند؛ اجرای فرزند و هر تأیید محیط محافظت‌شده باید با SHA فرزند تأییدشده مطابقت داشته باشد. تگ انتشار پیش از هر تلاش انتشار و تغییر ناشر مورداعتماد دوباره بررسی می‌شود.

job بسته‌بندی یک artifact تغییرناپذیر بارگذاری می‌کند که نام، شناسه/digest آن در Actions، اجرا/تلاش تولیدکننده، SHA هدف و SHA-256/اندازه tarball هر بسته به jobهای اعتبارسنجی و محافظت‌شده منتقل می‌شوند. job محافظت‌شده فقط ابزار مورداعتماد main را دریافت می‌کند، چندتایی artifact را از طریق GitHub API اعتبارسنجی می‌کند، آن را با شناسه دقیق artifact بارگیری می‌کند، همه tarballها را دوباره هش می‌کند و مسیرهای محلی TAR و هویت بسته را با قواعد متعارف‌سازی USTAR در CLI سنجاق‌شده اعتبارسنجی می‌کند. سپس هر نامزد از اجرای آزمایشی انتشار CLI سنجاق‌شده عبور می‌کند که پیش از جست‌وجوی رجیستری یا احراز هویت بازمی‌گردد. پیش‌فیلتر job اعتبارنامه، ClawPackهای فشرده را به 120 MiB، کل payload فایل را به 50 MiB، داده TAR گسترش‌یافته را به 64 MiB و تعداد ورودی‌های TAR را به 10,000 محدود می‌کند. ترمیم ناشر مورداعتماد برای بسته موجود همچنان فقط پیکربندی است، اما باز هم هدف را بسته‌بندی می‌کند و پیش از تغییر پیکربندی ناشر مورداعتماد، به تگ درخواستی و برابری دقیق بایت و فراداده رجیستری نیاز دارد. اعتبارسنجی پس از انتشار، artifact را از ClawHub بارگیری می‌کند و همان SHA-256 و اندازه را الزامی می‌داند. بازیابی با اجرای مجدد موارد ناموفق تنها زمانی می‌تواند از artifact بسته متعلق به تلاش قبلی دوباره استفاده کند که job دقیق تولیدکننده با موفقیت کامل شده باشد. شواهد نهایی همچنین نسخه قفل‌شده ClawHub، SHA-256 قفل و integrity مربوط به 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: شناسه اجرای پیش‌بررسی موفق موجود که در مسیر انتشار واقعی الزامی است تا گردش‌کار به‌جای ساخت مجدد، از tarball آماده‌شده دوباره استفاده کند
  • 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 با head دقیق؛ برای انتشار واقعی هسته 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، شرایط واجد بودن extended-stable ماهانه را دور می‌زند و در عین حال بررسی‌های هویت انتشار، artifact، تأیید و بازخوانی را حفظ می‌کند.

Plugin NPM Release، npm_dist_tag=default را برای رفتار انتشار موجود یا npm_dist_tag=extended-stable را برای مسیر ماهانه محافظت‌شده می‌پذیرد. گزینه extended-stable به publish_scope=all-publishable، ورودی خالی plugins، یک پچ نهایی در 33 یا بالاتر و شاخه متعارف extended-stable/YYYY.M.33 در نوک دقیق آن نیاز دارد. این گزینه هرگز latest یا beta مربوط به Plugin را جابه‌جا نمی‌کند. نسخه‌های جدید بسته، 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 تأییدشده برای نامزد، از نام‌های فعلی نصب‌کننده ویندوز به digestهای سنجاق‌شده 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 است تا دسترس‌پذیری npm توسط sidecar مربوط به ClawHub مسدود نشود؛ 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 استفاده کند که در پیش‌بررسی استفاده شده است؛ گردش‌کار پیش از ادامه انتشار، آن فراداده را تأیید می‌کند

توالی عادی انتشار بتا/آخرین نسخه پایدار

این توالی قدیمی برای انتشار هماهنگ‌شده عادی است که مالک Pluginها، GitHub Release، Windows و سایر کارهای پلتفرمی نیز هست. این مسیر، مسیر ماهانه پایدارِ تمدیدشده Gateway در .33+ نیست که در ابتدای این صفحه مستند شده است.

هنگام آماده‌سازی یک انتشار پایدار هماهنگ‌شده عادی:

  1. OpenClaw NPM Release را با preflight_only=true اجرا کنید. پیش از وجود تگ، می‌توانید از SHA کامل کامیت فعلی شاخه گردش‌کار برای اجرای آزمایشیِ صرفاً اعتبارسنجیِ گردش‌کار پیش‌بررسی استفاده کنید.
  2. برای جریان عادیِ ابتدا بتا، npm_dist_tag=beta را انتخاب کنید؛ فقط زمانی latest را انتخاب کنید که عمداً انتشار مستقیم پایدار می‌خواهید.
  3. وقتی می‌خواهید CI عادی به‌همراه پوشش زنده کش پرامپت، Docker، QA Lab، Matrix و Telegram را از یک گردش‌کار دستی اجرا کنید، Full Release Validation را روی شاخه انتشار، تگ انتشار یا SHA کامل کامیت اجرا کنید. اگر عمداً فقط به گراف آزمون عادی و قطعی نیاز دارید، به‌جای آن گردش‌کار دستی 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 اجرا کنید. این فرایند پیش از ارتقای بسته npm مربوط به OpenClaw، Pluginهای برون‌سپاری‌شده را در npm و ClawHub منتشر می‌کند.
  7. اگر انتشار روی beta قرار گرفت، از گردش‌کار openclaw/releases/.github/workflows/openclaw-npm-dist-tags.yml برای ارتقای آن نسخه پایدار از beta به latest استفاده کنید.
  8. اگر انتشار عمداً مستقیماً در latest انجام شد و beta باید بی‌درنگ همان بیلد پایدار را دنبال کند، از همان گردش‌کار انتشار استفاده کنید تا هر دو dist-tag را به نسخه پایدار اشاره دهید، یا اجازه دهید همگام‌سازی زمان‌بندی‌شده و خودترمیم آن بعداً beta را جابه‌جا کند.

تغییر dist-tag در مخزن دفترکل انتشار قرار دارد، زیرا همچنان به NPM_TOKEN نیاز دارد؛ درحالی‌که مخزن منبع انتشار را فقط از طریق OIDC نگه می‌دارد. به‌این‌ترتیب، هم مسیر انتشار مستقیم و هم مسیر ارتقای ابتدا بتا مستند و برای اپراتور قابل‌مشاهده باقی می‌مانند.

اگر نگه‌دارنده‌ای ناچار است به احراز هویت محلی npm بازگردد، هرگونه فرمان CLI مربوط به 1Password ‏(op) را فقط در یک نشست اختصاصی tmux اجرا کنید. op را مستقیماً از پوسته اصلی عامل فراخوانی نکنید؛ نگه‌داشتن آن در tmux باعث می‌شود اعلان‌ها، هشدارها و مدیریت OTP قابل‌مشاهده باشند و از تکرار هشدارهای میزبان جلوگیری شود.

مراجع عمومی

نگه‌دارندگان برای راهنمای اجرایی واقعی از مستندات خصوصی انتشار در openclaw/maintainers/release/README.md استفاده می‌کنند.

مرتبط

Was this useful?
On this page

On this page