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 در حال حاضر سه کانال به‌روزرسانی روبه‌کاربر ارائه می‌کند:

  • stable: کانال انتشار ترویج‌شدهٔ موجود که تا زمان تحقق نقطه‌عطف جداگانهٔ CLI/کانال، همچنان از طریق npm latest تفکیک می‌شود
  • beta: برچسب‌های پیش‌انتشار که در npm beta منتشر می‌شوند
  • dev: سرِ متحرک main

به‌طور جداگانه، اپراتورهای انتشار می‌توانند بستهٔ هستهٔ آخرین ماه تکمیل‌شده را از وصلهٔ 33 به بعد در npm extended-stable منتشر کنند. خط نهایی عادی ماه جاری در npm latest ادامه می‌یابد؛ این تفکیک انتشار در سمت اپراتور به‌خودی‌خود تفکیک کانال به‌روزرسانی CLI را تغییر نمی‌دهد.

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

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

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

آهنگ انتشار

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

انتشار ماهانهٔ extended-stable فقط در npm

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

در شاخهٔ دقیق extended-stable، نسخهٔ بستهٔ ریشه را به YYYY.M.P افزایش دهید، pnpm release:prep را اجرا کنید و تأیید کنید که همهٔ بسته‌های افزونهٔ قابل‌انتشار نسخهٔ یکسانی دارند. همهٔ تغییرات تولیدشده را commit و push کنید، برچسب تغییرناپذیر vYYYY.M.P را در همان commit ایجاد و push کنید و 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 نمایهٔ موجود برای عمق اعتبارسنجی است؛ این نمایه از dist-tag مربوط به npm با نام extended-stable جداست و عمداً بدون تغییر باقی می‌ماند.

پس از موفقیت هر دو اجرا، همهٔ Pluginهای رسمی قابل‌انتشار در npm را از همان نوک دقیق شاخه منتشر کنید. وصلهٔ P باید 33 یا بیشتر باشد. SHA کامل انتشار را به‌عنوان ref ارسال کنید، منتظر تکمیل کامل ماتریس و بازخوانی رجیستری بمانید، سپس شناسهٔ اجرای موفق Plugin NPM Release را ذخیره کنید:

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 استفاده می‌کند، از جمله بسته‌هایی که منبع آن‌ها تغییر نکرده است. پیش از موفقیت، هر بستهٔ دقیق و هر برچسب extended-stable مربوط به Plugin را تأیید می‌کند. اگر یک اجرای جزئی ناموفق شد، همان فرمان را دوباره اجرا کنید: بسته‌های ازقبل‌منتشرشده دوباره استفاده می‌شوند، برچسب‌های مفقود یا قدیمی Plugin در محیط انتشار npm تطبیق داده می‌شوند و بازخوانی نهایی همچنان مجموعهٔ کامل بسته‌ها را پوشش می‌دهد.

پس از موفقیت گردش‌کار Plugin و آماده‌شدن محیط انتشار npm، tarball دقیق پیش‌بررسی هسته را منتشر کنید. انتشار هسته تأیید می‌کند که اجرای Plugin ارجاع‌شده در همان شاخهٔ متعارف و SHA دقیق منبع، completed/success است:

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>

برای یک fork یا تمرین غیرتولیدی که عمداً نمی‌تواند سیاست ماهانهٔ .33 یا ماهِ main محافظت‌شده را برآورده کند، -f bypass_extended_stable_guard=true را به هر دو dispatch پیش‌بررسی و انتشار npm اضافه کنید. مقدار پیش‌فرض false است. این دورزدن فقط همراه با npm_dist_tag=extended-stable پذیرفته می‌شود و در خلاصهٔ گردش‌کار ثبت می‌شود. این گزینه ارجاع متعارف گردش‌کار extended-stable/YYYY.M.33، برابری نوک شاخه/برچسب/نسخهٔ بررسی‌شده، نحو برچسب نهایی، برابری نسخهٔ بسته/برچسب، هویت اجرا و manifest ارجاع‌شده، منشأ tarball، تأیید محیط، بازخوانی رجیستری یا شواهد اصلاح selector را دور نمی‌زند.

گردش‌کار انتشار، هویت اجراهای ارجاع‌شدهٔ پیش‌بررسی، اعتبارسنجی و Plugin، digest مربوط به tarball آماده‌شده و selectorهای رجیستری هسته را تأیید می‌کند. پس از موفقیت گردش‌کار، نتیجه را به‌طور مستقل تأیید کنید:

bash
npm view [email protected] version --userconfig "$(mktemp)"npm view openclaw@extended-stable version --userconfig "$(mktemp)"

هر دو فرمان باید YYYY.M.P را برگردانند. اگر انتشار موفق شد اما بازخوانی selector ناموفق بود، نسخهٔ تغییرناپذیر بسته را دوباره منتشر نکنید. از تنها فرمان اصلاح npm dist-tag add [email protected] extended-stable که در خلاصهٔ always-run گردش‌کار ناموفق چاپ شده است استفاده کنید، سپس هر دو بازخوانی مستقل را تکرار کنید. بازگردانی به selector قبلی یک تصمیم جداگانهٔ اپراتور است، نه مسیر اصلاح بازخوانی.

مستندات پشتیبانی عمومی در ابتدا Slack، Discord و Codex را به‌عنوان سطوح Plugin تحت پوشش extended-stable مشخص می‌کنند. این فهرست یک بیانیهٔ پشتیبانی است، نه فهرست مجاز در کد انتشار: همهٔ Pluginهای رسمی قابل‌انتشار در npm از همان مسیر انتشار با نسخهٔ دقیق یکسان پیروی می‌کنند.

چک‌لیست عادی زیر همچنان انتشار بتا، latest، انتشار GitHub، Pluginها، macOS، Windows و سایر پلتفرم‌ها را بر عهده دارد. این مراحل را برای این مسیر extended-stable فقط مخصوص npm اجرا نکنید.

چک‌لیست اپراتور انتشار عادی

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

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

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

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

  7. اعتبارسنجی کامل انتشارِ متصل به SHA را برای SHA انتشار، با استفادهٔ مجدد از شواهد فعال، اجرا کنید. والد سبک‌وزن باید changelog-only-release-v1 را ثبت کند، به SHA کد سبز اشاره کند و هیچ lane فرزند محصولی را dispatch نکند. این کار شواهد محصول را دوباره استفاده می‌کند؛ بایت‌های بسته را دوباره استفاده نمی‌کند.

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

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

    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 منطبق ترویج می‌دهد. checkout انتشار همچنان ریشهٔ محصول/داده باقی می‌ماند، درحالی‌که برنامه‌ریزی و تأیید نهایی از checkout دقیق و مورداعتماد منبع workflow اجرا می‌شوند تا یک commit قدیمی‌تر انتشار نتواند بی‌سروصدا از ابزار انتشار منسوخ استفاده کند. پیش از شروع هر فرایند فرزند انتشار، متن دقیق انتشار GitHub را رندر و cache می‌کند. وقتی بخش کامل و منطبق CHANGELOG.md در محدودیت 125,000 نویسه‌ای GitHub و سقف ایمنی منطبق 125,000 بایتی رندرکننده جای بگیرد، صفحه دقیقاً همان بخش ## YYYY.M.PATCH را همراه با عنوانش در بر می‌گیرد. وقتی بخش منبع جای نمی‌گیرد، صفحه یادداشت‌های ویراستاری گروه‌بندی‌شده را دقیقاً حفظ می‌کند و سابقهٔ مشارکت بیش‌ازحد بزرگ را با پیوندی پایدار به سابقهٔ کامل در CHANGELOG.md سنجاق‌شده به tag جایگزین می‌کند؛ سوابق ناقص و موارد فهرستِ بریده‌شده هرگز منتشر نمی‌شوند. workflow پیش از افزودن ### Release verification، متن کامل یا فشرده را انتخاب می‌کند؛ اگر دنبالهٔ مدرک از محدودیت عبور کند، متن مرجع را حفظ می‌کند و در عوض به مدرک پیوست‌شده و تغییرناپذیر متکی می‌ماند. انتشارهای پایدار منتشرشده در npm latest به آخرین انتشار GitHub تبدیل می‌شوند، درحالی‌که انتشارهای نگه‌داری پایدار که در npm روی beta نگه داشته می‌شوند، با GitHub latest=false ایجاد می‌شوند. workflow همچنین مدرک وابستگی پیش‌بررسی، manifest اعتبارسنجی کامل و مدرک تأیید registry پس از انتشار را برای پاسخ‌گویی به رخدادهای پس از انتشار در انتشار GitHub بارگذاری می‌کند. این workflow شناسه‌های اجرای فرزند را بی‌درنگ چاپ می‌کند، دروازه‌های محیط انتشار را که توکن workflow مجاز به تأییدشان است به‌طور خودکار تأیید می‌کند، jobهای فرزند ناموفق را همراه با انتهای logها خلاصه می‌کند، صفحهٔ پیش‌نویس انتشار GitHub را از ابتدا می‌سازد و آرتیفکت‌های Windows و Android را هم‌زمان با انتشار npm متعلق به OpenClaw ترویج می‌کند، پس از موفقیت آن مراحل صفحهٔ انتشار و مدرک وابستگی را نهایی می‌کند، هرگاه npm متعلق به OpenClaw در حال انتشار باشد منتظر ClawHub می‌ماند، سپس تأییدکنندهٔ beta روی main مورداعتماد را اجرا می‌کند و مدرک پس از انتشار مربوط به انتشار GitHub، بستهٔ npm، بسته‌های npm انتخاب‌شدهٔ Plugin، بسته‌های انتخاب‌شدهٔ ClawHub، شناسه‌های اجرای workflow فرزند و شناسهٔ اختیاری اجرای NPM Telegram را بارگذاری می‌کند. تأییدکنندهٔ راه‌اندازی ClawHub به مسیر و SHA دقیق workflow روی main مورداعتماد، تلاش‌های اجرای تولیدکننده و پایانی، SHA انتشار، مجموعهٔ بستهٔ درخواستی، چندتایی تغییرناپذیر آرتیفکت بسته و آرتیفکت بازخوانی پایانی registry نیاز دارد؛ اجرای موفق قدیمی روی release-ref پذیرفته نمی‌شود.

    سپس پذیرش بستهٔ پس از انتشار را روی بستهٔ منتشرشدهٔ [email protected] یا openclaw@beta اجرا کنید. اگر یک پیش‌انتشار pushشده یا منتشرشده به اصلاح نیاز دارد، شمارهٔ پیش‌انتشار منطبق بعدی را ایجاد کنید؛ نسخهٔ قدیمی را هرگز حذف یا بازنویسی نکنید.

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

  11. برای نسخهٔ پایدار، فقط پس از آن ادامه دهید که beta یا release candidate بررسی‌شده، مدارک اعتبارسنجی لازم را داشته باشد. انتشار پایدار npm نیز از OpenClaw Release Publish عبور می‌کند و با preflight_run_id از آرتیفکت موفق پیش‌بررسی دوباره استفاده می‌کند. آمادگی انتشار پایدار macOS همچنین به .zip، .dmg، .dSYM.zip بسته‌بندی‌شده و appcast.xml به‌روزشده روی main نیاز دارد؛ workflow انتشار macOS پس از تأیید آرتیفکت‌های انتشار، appcast امضاشده را به‌طور خودکار در main عمومی منتشر می‌کند، یا اگر حفاظت branch مانع push مستقیم شود یک PR برای appcast باز می‌کند یا به‌روزرسانی می‌کند. آمادگی پایدار Windows Hub به آرتیفکت‌های امضاشدهٔ OpenClawCompanion-Setup-x64.exe، OpenClawCompanion-Setup-arm64.exe و OpenClawCompanion-SHA256SUMS.txt در انتشار GitHub متعلق به OpenClaw نیاز دارد. tag دقیق انتشار امضاشدهٔ openclaw/openclaw-windows-node را به‌عنوان windows_node_tag و نگاشت digest نصب‌کنندهٔ تأییدشده توسط candidate آن را به‌عنوان 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 را forward-port کنید. سازگارکننده‌های مختص انتشار برای سازگاری، آزمون یا اعتبارسنجی را کورکورانه در main جدیدتر ادغام نکنید.
  2. برای مسیر عادی، main را روی نسخهٔ پایدار عرضه‌شده تنظیم کنید. نهایی‌سازی دیرهنگام می‌تواند پس از پیشروی main به CalVer پایدار جدیدتر OpenClaw از آن استفاده کند؛ یک قطار انتشارِ ازقبل آغازشده را صرفاً برای بستن انتشار قبلی downgrade نکنید. اعتبارسنج همچنان به بخش دقیق changelog عرضه‌شده و ورودی appcast نیاز دارد و نسخه و SHA واقعی main را ثبت می‌کند. پس از هر تغییر نسخهٔ ریشه، pnpm release:prep و سپس pnpm deps:shrinkwrap:generate را اجرا کنید.
  3. بخش ## YYYY.M.PATCH متعلق به CHANGELOG.md را روی main دقیقاً با branch انتشار tagشده منطبق کنید. اگر انتشار Mac یک به‌روزرسانی منتشر کرده است، به‌روزرسانی پایدار appcast.xml را نیز بگنجانید.
  4. تا زمانی که اپراتور صراحتاً آن قطار انتشار را آغاز نکرده است، YYYY.M.PATCH+1، یک نسخهٔ beta یا بخش خالی changelog آینده را به main اضافه نکنید.
  5. فرمان‌های pnpm release:generated:check، pnpm deps:shrinkwrap:check و OPENCLAW_TESTBOX=1 pnpm check:changed را اجرا کنید. push کنید، سپس پیش از اعلام پایان انتشار پایدار تأیید کنید که origin/main شامل نسخه و changelog عرضه‌شده است.
  6. متغیرهای مخزن RELEASE_ROLLBACK_DRILL_ID و RELEASE_ROLLBACK_DRILL_DATE را پس از هر تمرین rollback خصوصی به‌روز نگه دارید.

OpenClaw Stable Main Closeout از push مربوط به main آغاز می‌شود که پس از انتشار پایدار، نسخه، changelog و appcast عرضه‌شده را در بر دارد. این فرایند مدرک تغییرناپذیر پس از انتشار را می‌خواند تا tag عرضه‌شده را به اجراهای Full Release Validation و Publish آن متصل کند، سپس وضعیت پایدار main، انتشار، دورهٔ پایدار soak اجباری و مدرک مسدودکنندهٔ کارایی را تأیید می‌کند. همچنین یک manifest تغییرناپذیر نهایی‌سازی و checksum آن را به انتشار GitHub پیوست می‌کند. محرک خودکار push، انتشارهای قدیمی‌تر از مدرک تغییرناپذیر پس از انتشار را رد می‌کند و هرگز این ردشدن را نهایی‌سازی کامل‌شده تلقی نمی‌کند.

یک نهایی‌سازی کامل به هر دو آرتیفکت و checksum منطبق نیاز دارد. یک manifest ناقص، SHA ثبت‌شدهٔ main و تمرین rollback خود را بازپخش می‌کند تا بایت‌های یکسان را دوباره تولید کند و سپس checksum مفقود را پیوست می‌کند؛ یک جفت نامعتبر، یا checksum بدون manifest، همچنان مسدودکننده باقی می‌ماند. اجرای ناشی از push بدون متغیرهای مخزن مربوط به تمرین rollback، بدون تکمیل نهایی‌سازی رد می‌شود؛ رکورد مفقود یا قدیمی‌تر از 90 روز تمرین نیز همچنان نهایی‌سازی دستیِ مبتنی بر مدرک را مسدود می‌کند. فرمان‌های بازیابی خصوصی در runbook مخصوص نگه‌دارندگان باقی می‌مانند. dispatch دستی را فقط برای تعمیر یا بازپخش نهایی‌سازی پایدار مبتنی بر مدرک به‌کار ببرید.

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

یک tag اصلاحی fallback قدیمی فقط زمانی می‌تواند از مدرک بستهٔ پایه دوباره استفاده کند که tag اصلاحی به همان commit منبع tag پایدار پایه resolve شود. انتشار Android آن، APK تأییدشدهٔ tag پایه را دوباره استفاده می‌کند و منشأ tag اصلاحی را می‌افزاید. اصلاحی با منبع متفاوت باید مدرک بستهٔ خودش را منتشر و تأیید کند و از versionCode بالاتر Android استفاده کند.

پیش‌بررسی انتشار

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

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

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

  • پس از افزایش نسخهٔ ریشه و پیش از tagگذاری، pnpm release:prep را اجرا کنید. این فرمان همهٔ مولدهای قطعی انتشار را اجرا می‌کند که معمولاً پس از تغییر نسخه/config/API دچار انحراف می‌شوند: نسخه‌های Plugin، shrinkwrapهای npm، موجودی Plugin، schema پیکربندی پایه، metadata پیکربندی کانال‌های bundleشده، baseline مستندات پیکربندی، exportهای SDK مربوط به Plugin و baseline API متعلق به SDK مربوط به Plugin. pnpm release:check این محافظ‌ها را در حالت بررسی دوباره اجرا می‌کند (به‌علاوهٔ بررسی بودجهٔ سطح SDK مربوط به Plugin) و پیش از اجرای بررسی‌های انتشار بسته، همهٔ شکست‌های انحراف تولیدشده را در یک گذر گزارش می‌دهد.

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

  • workflow دستی Full Release Validation را پیش از تأیید انتشار اجرا کنید تا همهٔ test boxهای پیش از انتشار از یک نقطهٔ ورود آغاز شوند. این workflow یک branch، tag یا SHA کامل commit را می‌پذیرد، CI دستی را dispatch می‌کند و OpenClaw Release Checks را برای smoke نصب، پذیرش بسته، بررسی بسته در چند سیستم‌عامل، هم‌ارزی QA Lab، Matrix و مسیرهای Telegram dispatch می‌کند. اجراهای پایدار و کامل همیشه soak جامع live/E2E و مسیر انتشار Docker را شامل می‌شوند؛ run_release_soak=true برای یک soak صریح beta حفظ شده است. Package Acceptance در طول اعتبارسنجی candidate، E2E مرجع Telegram بسته را فراهم می‌کند و از یک poller زندهٔ هم‌زمان دوم جلوگیری می‌کند.

    پس از انتشار یک beta، release_package_spec را ارائه کنید تا بستهٔ npm عرضه‌شده بدون بازسازی tarball انتشار، در بررسی‌های انتشار، Package Acceptance و E2E بستهٔ Telegram دوباره استفاده شود. npm_telegram_package_spec را فقط وقتی ارائه کنید که Telegram باید از بستهٔ منتشرشده‌ای متفاوت با بقیهٔ اعتبارسنجی انتشار استفاده کند. package_acceptance_package_spec را وقتی ارائه کنید که Package Acceptance باید از بستهٔ منتشرشده‌ای متفاوت با مشخصات بستهٔ انتشار استفاده کند. 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 [email protected] -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 و مسیرهای بومی‌سازی Control UI را اجباری می‌کند. اجراهای مستقل و دستی CI فقط هنگام اجرا با include_android=true، Android را اجرا می‌کنند؛ 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> بارگذاری می‌کند و همچنین آن را در مسیر dependency-evidence/ داخل مصنوع آماده‌شدهٔ پیش‌بررسی npm می‌گنجاند. مسیر انتشار واقعی همان مصنوع پیش‌بررسی را دوباره به‌کار می‌گیرد و سپس همان شواهد را با نام openclaw-<version>-dependency-evidence.zip به انتشار GitHub پیوست می‌کند.

  • پس از ایجاد برچسب، برای توالی انتشار تغییردهنده OpenClaw Release Publish را اجرا کنید. انتشارهای عادی بتا و پایدار را از main مورداعتماد اجرا کنید؛ برچسب انتشار همچنان commit هدف دقیق را انتخاب می‌کند و ممکن است به 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ها نیاز دارند. اجراهای صرفاً مخصوص Plugin در all-publishable به شواهد کامل و تغییرناپذیر پیش‌بررسی و Full Release Validation نیاز دارند؛ شواهد ناقص رد می‌شوند.

  • 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 همچنین از اجاره اعتبارنامه‌های CI در Convex استفاده می‌کند. وقتی همه سناریوهای نگه‌داری‌شده Matrix را می‌خواهید، گردش‌کار دستی QA-Lab - All Lanes را با matrix_profile=all اجرا کنید؛ گردش‌کار این انتخاب را میان نمایه‌های انتقال، رسانه و E2EE توزیع می‌کند تا اثبات کامل در محدوده مهلت زمانی هر کار باقی بماند.

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

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

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

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

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

  • آن گردش‌کار، 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 برای plugin، ساخت، ساخت رابط کاربری و 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 (یا نسخه بتا/اصلاحی متناظر) را اجرا کنید تا مسیر نصب رجیستری منتشرشده در یک پیشوند موقت تازه اعتبارسنجی شود.

  • پس از انتشار بتا، [email protected] 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 را اعزام می‌کند، اجرای دقیق گردش‌کار را پایش می‌کند، آرتیفکت را بارگیری می‌کند و گزارش Telegram را چاپ می‌کند.

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

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

    • انتشار واقعی npm باید یک preflight_run_id موفق npm را پشت سر بگذارد.
    • هماهنگ‌سازی و پیش‌بررسی انتشار معمول بتا و پایدار، از main قابل‌اعتماد در برابر برچسب هدف دقیق استفاده می‌کنند. انتشار و پیش‌بررسی آلفای Tideclaw از شاخه آلفای متناظر استفاده می‌کنند.
    • انتشارهای پایدار npm به‌طور پیش‌فرض از beta استفاده می‌کنند؛ انتشار پایدار npm می‌تواند از طریق ورودی گردش‌کار، latest را صریحاً هدف قرار دهد.
    • تغییر dist-tag در 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 باید preflight_run_id و validate_run_id موفق macOS را پشت سر بگذارد.
    • مسیرهای انتشار واقعی، آرتیفکت‌های آماده‌شده را ارتقا می‌دهند و دوباره آن‌ها را نمی‌سازند.

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

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

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

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

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

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

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

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

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

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

پس از سبز شدن SHA کد، فقط CHANGELOG.md را کامیت کنید و همان ابزار کمکی را با 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 Release Validation، normal_ci، plugin_prerelease و release_checks را موفق نشان دهد، مگر اینکه اجرای مجدد متمرکز عمداً فرزند جداگانه Plugin Prerelease را رد کرده باشد. از فرزند مستقل npm-telegram فقط برای اجرای مجدد متمرکز بسته منتشرشده با release_package_spec یا npm_telegram_package_spec استفاده کنید. خلاصه نهایی اعتبارسنج شامل جدول‌های کندترین کارها برای هر اجرای فرزند است تا مدیر انتشار بتواند مسیر بحرانی فعلی را بدون بارگیری گزارش‌ها ببیند.

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

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

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

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

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

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

OpenClaw Release Checks از مرجع قابل‌اعتماد گردش‌کار استفاده می‌کند تا مرجع هدف را یک‌بار به‌صورت release-package-under-test حل کند و هنگام اجرای soak، همان آرتیفکت را در بررسی‌های چندسیستم‌عاملی، پذیرش بسته و بررسی‌های Docker مسیر انتشار دوباره به کار ببرد. این کار همه جعبه‌های مرتبط با بسته را روی بایت‌های یکسان نگه می‌دارد و از ساخت مکرر بسته جلوگیری می‌کند. پس از آنکه یک نسخه بتا روی npm قرار گرفت، [email protected] را تنظیم کنید تا بررسی‌های انتشار بسته ارائه‌شده را یک‌بار بارگیری کنند، SHA مبدأ ساخت آن را از dist/build-info.json استخراج کنند و همان آرتیفکت را برای مسیرهای چندسیستم‌عاملی، پذیرش بسته، Docker مسیر انتشار و Telegram بسته دوباره به کار ببرند.

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

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

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 [email protected] \  -f [email protected] \  -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-*، بررسی‌های smoke مصنوع ساخته‌شده، بررسی‌های مستندات، 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 انتشار شامل موارد زیر است:

  • بررسی smoke نصب کامل با بررسی smoke کند نصب سراسری Bun فعال
  • آماده‌سازی/استفادهٔ مجدد از تصویر smoke مربوط به Dockerfile ریشه بر اساس SHA هدف، با jobهای smoke مربوط به QR، ریشه/Gateway و نصب‌کننده/Bun که به‌صورت shardهای جداگانهٔ install-smoke اجرا می‌شوند
  • مسیرهای E2E مخزن
  • بخش‌های Docker مسیر انتشار: core، package-update-openai، package-update-anthropic، package-update-core، plugins-runtime-plugins، plugins-runtime-services، plugins-runtime-install-a تا plugins-runtime-install-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 انتشار شامل موارد زیر است:

  • مسیر برابری mock که مسیر نامزد 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 برای نامزدی که قبلاً عرضه شده، با source=ref برای tarball محلی npm مبتنی بر SHA پیش از انتشار، با source=trusted-url برای آینهٔ سازمانی/خصوصی تحت مالکیت نگه‌دارنده، یا با source=artifact برای tarball آماده‌شده‌ای که اجرای دیگری از GitHub Actions بارگذاری کرده است، استفاده کنید.

این، جایگزین بومی 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 [email protected]

پروفایل‌های رایج بسته:

  • smoke: مسیرهای نصب سریع بسته/کانال/عامل، شبکه Gateway و بارگذاری مجدد پیکربندی
  • package: قراردادهای نصب/به‌روزرسانی/راه‌اندازی مجدد/بسته Plugin به‌همراه اثبات زنده نصب skill از ClawHub؛ این گزینه پیش‌فرض بررسی انتشار است
  • product: package به‌همراه کانال‌های MCP، پاک‌سازی cron/زیرعامل، جست‌وجوی وب OpenAI و OpenWebUI
  • full: بخش‌های مسیر انتشار Docker به‌همراه OpenWebUI
  • custom: فهرست دقیق docker_lanes برای اجرای مجدد متمرکز

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

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

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

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

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

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 تنظیم کنید، یا گردش‌کار فرزند را مستقیماً dispatch کنید.

راه‌اندازی اولیه ClawHub برای نخستین انتشار یک استثنا است: Plugin ClawHub New را از main مورداعتماد dispatch کنید و 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، checkout و بسته‌بندی می‌کند، زنجیره‌ابزار قفل‌شده ClawHub را ایجاد می‌کند و پیش از وجود تگ انتشار، آرتیفکت تغییرناپذیر و slug/هویت بسته را اعتبارسنجی می‌کند. محیط clawhub-plugin-bootstrap را فقط پس از پایان jobهای بسته‌بندی بدون secret تأیید کنید؛ این job اعتبارسنجی محافظت‌شده هیچ اعتبارنامه یا فرمان تغییردهنده‌ای ندارد.

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

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

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 توسط مؤلفه جانبی 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 و سایر کارهای پلتفرمی نیز هست. این مسیر، مسیر ماهانه و صرفاً npm نسخه پایدار طولانی‌مدت .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