Release and CI

اعتبارسنجی کامل انتشار

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

آن را از یک مرجع گردش‌کار مورد اعتماد، معمولاً main، اجرا کنید و شاخهٔ انتشار، برچسب یا SHA کامل کامیت را به‌عنوان ref ارسال کنید:

bash

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

provider برای راه‌اندازی اولیهٔ میان‌سیستم‌عاملی و نوبت سرتاسری عامل، مقادیر anthropic یا minimax را نیز می‌پذیرد. کارهای فرزندِ قابل استفادهٔ مجدد، سازوکار گردش‌کار فراخوانی‌شده را از job.workflow_repository و job.workflow_sha تفکیک می‌کنند، درحالی‌که ورودی ref نامزد تحت آزمون را انتخاب می‌کند. این کار هنگام اعتبارسنجی یک شاخه یا برچسب انتشار قدیمی‌تر، منطق اعتبارسنجی جاری و مورد اعتماد را در دسترس نگه می‌دارد.

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

release_profile=stable و release_profile=full همیشه آزمون ماندگاری جامع زنده/Docker را اجرا می‌کنند. برای گنجاندن همان مسیرهای آزمون ماندگاری با نمایهٔ beta، مقدار run_release_soak=true را ارسال کنید. انتشار پایدار، مانیفست اعتبارسنجی فاقد این آزمون ماندگاری و شواهد مسدودکنندهٔ عملکرد محصول را رد می‌کند.

Package Acceptance معمولاً بستهٔ tar نامزد را از ref تفکیک‌شده می‌سازد؛ این شامل اجراهای SHA کامل اعزام‌شده با pnpm ci:full-release نیز می‌شود. پس از انتشار بتا، برای استفادهٔ دوباره از بستهٔ npm منتشرشده در بررسی‌های انتشار، Package Acceptance، میان‌سیستم‌عاملی، Docker مسیر انتشار و Telegram بسته، مقدار release_package_spec=openclaw@YYYY.M.PATCH-beta.N را ارسال کنید. تنها زمانی از package_acceptance_package_spec استفاده کنید که Package Acceptance باید عمداً بستهٔ متفاوتی را اثبات کند. مسیر بستهٔ زندهٔ Plugin مربوط به Codex نیز از همین وضعیت پیروی می‌کند: مقادیر منتشرشدهٔ release_package_spec مقدار codex_plugin_spec=npm:@openclaw/codex@<version> را مشتق می‌کنند؛ اجراهای SHA/آرتیفکت، extensions/codex را از مرجع انتخاب‌شده بسته‌بندی می‌کنند؛ و اپراتورها می‌توانند codex_plugin_spec را مستقیماً برای منابع Plugin از نوع npm:، npm-pack: یا git: تنظیم کنند. این مسیر، تأیید صریح نصب Codex CLI را که آن Plugin نیاز دارد اعطا می‌کند، سپس پیش‌بررسی Codex CLI و نوبت‌های عامل OpenAI در همان نشست را اجرا می‌کند.

مراحل سطح‌بالا

برای rerun_group=all، ابتدا کار Check for reusable validation evidence اجرا می‌شود: این کار جدیدترین اعتبارسنجی کامل موفق پیشین را برای دقیقاً همان SHA هدف، نمایهٔ انتشار، تنظیم مؤثر آزمون ماندگاری و ورودی‌های اعتبارسنجی جست‌وجو می‌کند. هنگامی که چنین شواهدی وجود داشته باشد، همهٔ مسیرها رد می‌شوند و اعتبارسنج چتری آرتیفکت تغییرناپذیر والد، اجراهای فرزند و گزارش‌های اعزام را دوباره بررسی می‌کند. این فقط برای بازیابی اجرای مجدد همان نامزد است و استفادهٔ مجدد میان SHAهای مختلف را مجاز نمی‌کند. برای نامزد تغییریافته، همهٔ دروازه‌های بسته، آرتیفکت، نصب، Docker یا ارائه‌دهنده را که از آن تفاوت تأثیر می‌پذیرند دوباره اجرا کنید. برای اجبار اجرای کامل و تازه، reuse_evidence=false را ارسال کنید. استفادهٔ مجدد از شواهد فقط از main یا یک مرجع متعارف و سنجاق‌شده به SHA از نوع release-ci/* اجرا می‌شود که کامیت گردش‌کار آن همچنان در تبار مورد اعتماد main باشد؛ سایر مراجع گردش‌کار، مسیرهای انتخاب‌شده را به‌صورت تازه اجرا می‌کنند.

همچنین برای rerun_group=all، کار Verify Docker runtime image assets هدف Docker با نام runtime-assets را با OPENCLAW_EXTENSIONS=diagnostics-otel,codex می‌سازد. این کار به‌موازات مراحل دیگر اجرا می‌شود و اعتبارسنج چتری آن را الزام می‌کند؛ مسیرها دیگر پیش از اعزام منتظر آن نمی‌مانند. یک rerun_group محدودتر این پیش‌بررسی را رد می‌کند.

مرحله	جزئیات
تفکیک هدف	کار: `Resolve target ref`
گردش‌کار فرزند: ندارد
اثبات می‌کند: شاخهٔ انتشار، برچسب یا SHA کامل کامیت را تفکیک و ورودی‌های انتخاب‌شده را ثبت می‌کند.
اجرای مجدد: اگر این مرحله شکست خورد، چتر را دوباره اجرا کنید.
پیش‌بررسی دارایی‌های Docker	کار: `Verify Docker runtime image assets`
گردش‌کار فرزند: ندارد
اثبات می‌کند: هدف ساخت Docker با نام `runtime-assets` پیش از اعزام هر مرحلهٔ دیگر همچنان با موفقیت انجام می‌شود. فقط برای `rerun_group=all` اجرا می‌شود.
اجرای مجدد: چتر را با `rerun_group=all` دوباره اجرا کنید.
Vitest و CI عادی	کار: `Run normal full CI`
گردش‌کار فرزند: `CI`
اثبات می‌کند: نمودار کامل و دستی CI را در برابر مرجع هدف اجرا می‌کند؛ شامل مسیرهای Linux Node، قطعه‌های Plugin همراه، قطعه‌های قرارداد Plugin و کانال، سازگاری Node 22، `check-`، `check-additional-`، بررسی‌های سریع آرتیفکت ساخته‌شده، بررسی‌های مستندات، Skills پایتون، Windows، macOS، بومی‌سازی Control UI و Android از طریق چتر.
اجرای مجدد: `rerun_group=ci`.
پیش‌انتشار Plugin	کار: `Run plugin prerelease validation`
گردش‌کار فرزند: `Plugin Prerelease`
اثبات می‌کند: بررسی‌های ایستای ویژهٔ انتشار Plugin، پوشش عاملی Plugin، قطعه‌های کامل دسته‌ای Plugin، مسیرهای Docker پیش‌انتشار Plugin و یک آرتیفکت غیرمسدودکنندهٔ `plugin-inspector-advisory` برای تریاژ سازگاری.
اجرای مجدد: `rerun_group=plugin-prerelease`.
بررسی‌های انتشار	کار: `Run release/live/Docker/QA validation`
گردش‌کار فرزند: `OpenClaw Release Checks`
اثبات می‌کند: بررسی سریع نصب، بررسی‌های بستهٔ میان‌سیستم‌عاملی، Package Acceptance، هم‌ترازی QA Lab، Matrix زنده و Telegram زنده. نمایه‌های پایدار و کامل، مجموعه‌های جامع زنده/E2E و بخش‌های Docker مسیر انتشار را نیز اجرا می‌کنند؛ بتا می‌تواند با `run_release_soak=true` به آن بپیوندد.
اجرای مجدد: `rerun_group=release-checks` یا یک دستگیرهٔ محدودتر بررسی‌های انتشار.
Telegram بسته	کار: `Run package Telegram E2E`
گردش‌کار فرزند: `NPM Telegram Beta E2E`
اثبات می‌کند: هنگامی که `release_package_spec` یا `npm_telegram_package_spec` تنظیم شده باشد، یک E2E متمرکز Telegram برای بستهٔ منتشرشده اجرا می‌شود. اعتبارسنجی کامل نامزد به‌جای آن از E2E متعارف Telegram در Package Acceptance استفاده می‌کند.
اجرای مجدد: `rerun_group=npm-telegram` همراه با `release_package_spec` یا `npm_telegram_package_spec`.
عملکرد محصول	کار: `Run product performance evidence`
گردش‌کار فرزند: `OpenClaw Performance`
اثبات می‌کند: اجرای عملکرد نمایهٔ انتشار (`profile=release`، `repeat=3`، `fail_on_regression=true`، `publish_reports=false`) در برابر SHA هدف. خروجی Kova در آرتیفکت‌های گردش‌کار باقی می‌ماند و فرزند باید اثبات کند که منتشرکنندهٔ گزارش آن رد شده است. فقط برای `rerun_group=all` یا `rerun_group=performance` الزامی و مسدودکننده است؛ برای گروه‌های اجرای مجدد محدودتر الزامی نیست.
اجرای مجدد: `rerun_group=performance`.
اعتبارسنج چتری	کار: `Verify full validation`
گردش‌کار فرزند: ندارد
اثبات می‌کند: نتایج ثبت‌شدهٔ اجرای فرزند را دوباره بررسی می‌کند و جدول‌های کندترین کارها را از گردش‌کارهای فرزند می‌افزاید.
اجرای مجدد: پس از اجرای مجدد یک فرزند ناموفق تا رسیدن به وضعیت موفق، فقط همین کار را دوباره اجرا کنید.

چتر همیشه عملکرد محصول را در حالت فقط آرتیفکت اعزام می‌کند. OpenClaw Performance انتشار گزارش را فقط برای اجراهای زمان‌بندی‌شده یا اعزام دستی‌ای مجاز می‌داند که صراحتاً publish_reports=true را تنظیم کرده باشد. محافظ فقط آرتیفکت باید با موفقیت تکمیل شود و اثبات کند که کار منتشرکننده رد شده است. شواهد تازه و استفاده‌شدهٔ مجدد، controls.performanceReportPublication=artifact-only را ثبت می‌کنند؛ اعتبارسنج و انتخاب‌گر استفادهٔ مجدد، شواهدی را که فاقد اثبات نرمال‌شدهٔ منطبق از فرزند عملکرد باشند رد می‌کنند.

اعتبارسنج، مانیفست متعارف را با نام full-release-validation-<run-id>-<run-attempt> بارگذاری می‌کند. ابزارهای شواهد، شناسهٔ آرتیفکت، چکیده، اجرای تولیدکننده و تلاش آن را پیش از دانلود همان شناسهٔ دقیق آرتیفکت اعتبارسنجی می‌کنند. این ابزارها اندازهٔ ZIP دانلودشده را محدود می‌کنند، بایت‌های آن را در برابر چکیدهٔ REST از نوع sha256: تأیید می‌کنند و تنها ورودی محدود و مجاز مانیفست را بدون استخراج بایگانی به‌صورت جریانی می‌خوانند. یک نام مستعار با نام پایدار موقتاً برای مصرف‌کنندگان قدیمی‌تر انتشار باقی می‌ماند. اعتبارسنج همیشه آرتیفکت دارای شناسهٔ تلاش را ترجیح می‌دهد؛ به‌عنوان یک گذار، نام پایدار را فقط برای تولیدکنندهٔ مانیفست v2 در تلاش نخست می‌پذیرد. این نام قدیمی را برای تلاش‌های بعدی و مانیفست v3 رد می‌کند.

برای ref=main همراه با rerun_group=all، برای مراجع release/* و برای مراجع آلفای Tideclaw، یک اجرای چتری جدیدتر، اجرای قدیمی‌تر با همان مرجع و گروه اجرای مجدد را منسوخ می‌کند. هنگامی که والد لغو شود، پایشگر آن هر گردش‌کار فرزندی را که پیش‌تر اعزام کرده است لغو می‌کند. اجراهای اعتبارسنجی برچسب و SHA سنجاق‌شده یکدیگر را لغو نمی‌کنند.

مراحل بررسی انتشار

OpenClaw Release Checks بزرگ‌ترین گردش‌کار فرزند است. هدف را یک‌بار تفکیک می‌کند و هنگامی که مراحل مرتبط با بسته یا Docker به آن نیاز داشته باشند، یک آرتیفکت مشترک release-package-under-test آماده می‌کند.

مرحله	جزئیات
هدف انتشار	کار: `Resolve target ref`
گردش‌کار پشتیبان: ندارد
آزمون‌ها: مرجع انتخاب‌شده، SHA مورد انتظار اختیاری، نمایه، گروه اجرای مجدد و فیلتر متمرکز مجموعه آزمون زنده.
اجرای مجدد: `rerun_group=release-checks`.
آرتیفکت بسته	کار: `Prepare release package artifact`
گردش‌کار پشتیبان: ندارد
آزمون‌ها: یک tarball نامزد را بسته‌بندی یا پیدا می‌کند و `release-package-under-test` را برای بررسی‌های پایین‌دستی مرتبط با بسته بارگذاری می‌کند.
اجرای مجدد: گروه بسته، چندسیستم‌عاملی یا زنده/E2E تحت تأثیر.
آزمون دود نصب	کار: `Run install smoke`
گردش‌کار پشتیبان: `Install Smoke`
آزمون‌ها: مسیر کامل نصب با استفاده مجدد از تصویر آزمون دود Dockerfile ریشه، نصب بسته QR، آزمون‌های دود Docker برای ریشه و Gateway، آزمون‌های Docker نصب‌کننده و آزمون دود ارائه‌دهنده تصویر برای نصب سراسری Bun.
اجرای مجدد: `rerun_group=install-smoke`.
چندسیستم‌عاملی	کار: `cross_os_release_checks`
گردش‌کار پشتیبان: `OpenClaw Cross-OS Release Checks (Reusable)`
آزمون‌ها: مسیرهای نصب تازه و ارتقا در Linux، Windows و macOS برای ارائه‌دهنده و حالت انتخاب‌شده، با استفاده از tarball نامزد به‌همراه یک بسته مبنا.
اجرای مجدد: `rerun_group=cross-os`.
E2E مخزن و زنده	کار: `Run repo/live E2E validation`
گردش‌کار پشتیبان: `OpenClaw Live And E2E Checks (Reusable)`
آزمون‌ها: E2E مخزن، حافظه نهان زنده، استریم WebSocket در OpenAI، شاردهای ارائه‌دهنده زنده بومی و Plugin و هارنس‌های مدل زنده/بک‌اند/Gateway مبتنی بر Docker که با `release_profile` انتخاب می‌شوند.
اجرا می‌شود در صورت: `run_release_soak=true`، ‏`release_profile=full` یا `rerun_group=live-e2e` متمرکز.
اجرای مجدد: `rerun_group=live-e2e`، در صورت نیاز همراه با `live_suite_filter`.
مسیر انتشار Docker	کار: `Run Docker release-path validation`
گردش‌کار پشتیبان: `OpenClaw Live And E2E Checks (Reusable)`
آزمون‌ها: بخش‌های Docker مسیر انتشار در برابر آرتیفکت بسته مشترک.
اجرا می‌شود در صورت: `run_release_soak=true`، ‏`release_profile=full` یا `rerun_group=live-e2e` متمرکز.
اجرای مجدد: `rerun_group=live-e2e`.
پذیرش بسته	کار: `Run package acceptance`
گردش‌کار پشتیبان: `Package Acceptance`
آزمون‌ها: فیکسچرهای آفلاین بسته Plugin، به‌روزرسانی Plugin، آزمون E2E مرجع بسته Telegram با OpenAI شبیه‌سازی‌شده و بررسی‌های بقای ارتقا از نسخه منتشرشده در برابر همان tarball. بررسی‌های مسدودکننده انتشار به‌طور پیش‌فرض از آخرین خط مبنای منتشرشده استفاده می‌کنند؛ بررسی‌های طولانی‌مدت (`run_release_soak=true`) دامنه را به ۴ انتشار پایدار اخیر npm به‌علاوه ۳ نسخه تاریخی سنجاق‌شده (`2026.4.23`، `2026.5.2`، `2026.4.15`) گسترش می‌دهند و در برابر فیکسچرهای ارتقای مربوط به مشکلات گزارش‌شده اجرا می‌شوند.
اجرای مجدد: `rerun_group=package`.
کارت امتیاز بلوغ	کار: `Render maturity scorecard release docs`
گردش‌کار پشتیبان: `maturity-scorecard.yml`
آزمون‌ها: مستندات مشورتی کارت امتیاز بلوغ را در برابر مرجع هدف رندر می‌کند. فقط هنگامی اجرا می‌شود که `run_maturity_scorecard=true` ارسال شده باشد.
اجرای مجدد: `rerun_group=qa` همراه با `run_maturity_scorecard=true`.
هم‌ارزی QA	کار: `Run QA Lab parity lane` و `Run QA Lab parity report`
گردش‌کار پشتیبان: کارهای مستقیم
آزمون‌ها: بسته‌های هم‌ارزی عامل‌محور نامزد و مبنا، سپس گزارش هم‌ارزی.
اجرای مجدد: `rerun_group=qa-parity` یا `rerun_group=qa`.
هم‌ارزی زمان‌اجرای QA	کار: `Run QA Lab runtime parity lane`
گردش‌کار پشتیبان: کار مستقیم
آزمون‌ها: یک مسیر هم‌ارزی عامل‌محور جفت زمان‌اجرای `openclaw`/`codex`‏ (`pnpm openclaw qa suite --runtime-pair openclaw,codex`)، شامل یک سطح استاندارد و با `run_release_soak=true`، یک سطح طولانی‌مدت. مشورتی: شکست‌های منفرد، تأییدکننده بررسی‌های انتشار را مسدود نمی‌کنند.
اجرای مجدد: `rerun_group=qa-parity` یا `rerun_group=qa`.
پوشش ابزار زمان‌اجرای QA	کار: `Enforce QA Lab runtime tool coverage`
گردش‌کار پشتیبان: کار مستقیم
آزمون‌ها: انحراف پویای ابزار میان `openclaw` و `codex` در سطح استاندارد هم‌ارزی زمان‌اجرا (`pnpm openclaw qa coverage --tools`)، با استفاده از خروجی مسیر هم‌ارزی زمان‌اجرای QA. مسدودکننده: ماهیت این کار را نمی‌توان به حالت مشورتی تغییر داد.
اجرای مجدد: `rerun_group=qa-parity` یا `rerun_group=qa`.
Matrix زنده QA	کار: `Run QA Lab live Matrix lane`
گردش‌کار پشتیبان: کار مستقیم
آزمون‌ها: نمایه سریع QA زنده Matrix در محیط `qa-live-shared`.
اجرای مجدد: `rerun_group=qa-live` یا `rerun_group=qa`.
Telegram زنده QA	کار: `Run QA Lab live Telegram lane`
گردش‌کار پشتیبان: کار مستقیم
آزمون‌ها: QA زنده Telegram با اجاره اعتبارنامه‌های CI از Convex.
اجرای مجدد: `rerun_group=qa-live` یا `rerun_group=qa`.
تأییدکننده انتشار	کار: `Verify release checks`
گردش‌کار پشتیبان: ندارد
آزمون‌ها: کارهای الزامی بررسی انتشار برای گروه اجرای مجدد انتخاب‌شده.
اجرای مجدد: پس از موفقیت کارهای فرزند متمرکز، دوباره اجرا شود.

بخش‌های مسیر انتشار Docker

مرحله مسیر انتشار Docker، هنگامی که live_suite_filter خالی است، بخش‌های زیر را اجرا می‌کند:

بخش	پوشش
`core`	مسیرهای آزمون دود هسته برای مسیر انتشار Docker.
`package-update-openai`	رفتار نصب/به‌روزرسانی بسته OpenAI، نصب درخواستی Codex، نوبت‌های زنده Plugin مربوط به Codex و فراخوانی ابزارهای Chat Completions.
`package-update-anthropic`	رفتار نصب و به‌روزرسانی بسته Anthropic.
`package-update-core`	رفتار بسته و به‌روزرسانی مستقل از ارائه‌دهنده.
`plugins-runtime-plugins`	مسیرهای زمان‌اجرای Plugin که رفتار Plugin را اعمال و بررسی می‌کنند.
`plugins-runtime-services`	مسیرهای زمان‌اجرای Plugin متکی به سرویس و زنده.
`plugins-runtime-install-a` تا `plugins-runtime-install-h`	دسته‌های نصب/زمان‌اجرای Plugin که برای اعتبارسنجی موازی انتشار تقسیم شده‌اند.
`openwebui`	آزمون دود سازگاری OpenWebUI که در صورت درخواست روی یک اجراکننده اختصاصی با دیسک بزرگ ایزوله می‌شود.

هنگامی که فقط یک مسیر Docker شکست خورده است، در گردش‌کار قابل‌استفاده‌مجدد زنده/E2E از docker_lanes=<lane[,lane]> هدفمند استفاده کنید. آرتیفکت‌های انتشار، در صورت موجود بودن، برای هر مسیر فرمان‌های اجرای مجدد را همراه با ورودی‌های استفاده مجدد از آرتیفکت بسته و تصویر ارائه می‌کنند.

نمایه‌های انتشار

release_profile عمدتاً گسترهٔ اجرای زنده/ارائه‌دهنده را در بررسی‌های انتشار کنترل می‌کند. این گزینه CI کامل عادی، پیش‌انتشار Plugin، آزمون دود نصب، پذیرش بسته یا آزمایشگاه QA را حذف نمی‌کند. پروفایل‌های پایدار و کامل همیشه پوشش جامع E2E مخزن/زنده و آزمون ماندگاری مسیر انتشار Docker را اجرا می‌کنند. پروفایل بتا می‌تواند با run_release_soak=true آن را فعال کند. پذیرش بسته، E2E مرجع Telegram بسته را برای هر نامزد کامل فراهم می‌کند؛ بنابراین گردش‌کار چتری آن پایشگر زنده را تکرار نمی‌کند.

پروفایل	کاربرد موردنظر	پوشش زنده/ارائه‌دهندهٔ گنجانده‌شده
`beta`	سریع‌ترین آزمون دود حیاتی برای انتشار.	مسیر زندهٔ OpenAI/هسته، مدل‌های زندهٔ Docker برای OpenAI، هستهٔ Gateway بومی، پروفایل Gateway بومی OpenAI، Plugin بومی OpenAI و Gateway زندهٔ Docker برای OpenAI.
`stable`	پروفایل پیش‌فرض تأیید انتشار.	`beta` به‌علاوهٔ آزمون دود Anthropic،‏ Google،‏ MiniMax، بخش پشتی، چارچوب آزمون زندهٔ بومی، بخش پشتی CLI زندهٔ Docker، اتصال ACP در Docker، چارچوب Codex در Docker، اعلان زیرعامل در Docker و یک شارد آزمون دود OpenCode Go.
`full`	پایش مشورتی گسترده.	`stable` به‌علاوهٔ ارائه‌دهندگان مشورتی، شاردهای زندهٔ Plugin و شاردهای زندهٔ رسانه.

افزوده‌های مختص پروفایل کامل

این مجموعه‌ها در stable نادیده گرفته می‌شوند و در full گنجانده شده‌اند:

حوزه	پوشش مختص پروفایل کامل
مدل‌های زندهٔ Docker	OpenCode Go،‏ OpenRouter،‏ xAI،‏ Z.ai و Fireworks.
Gateway زندهٔ Docker	ارائه‌دهندگان مشورتی که به شاردهای DeepSeek/Fireworks،‏ OpenCode Go/OpenRouter و xAI/Z.ai تقسیم شده‌اند.
پروفایل‌های ارائه‌دهندهٔ Gateway بومی	شاردهای کامل Anthropic Opus و Sonnet/Haiku،‏ Fireworks،‏ DeepSeek، شاردهای کامل مدل OpenCode Go،‏ OpenRouter،‏ xAI و Z.ai.
شاردهای زندهٔ Plugin بومی	Pluginهای A-K،‏ L-N، سایر موارد O-Z،‏ Moonshot و xAI.
شاردهای زندهٔ رسانهٔ بومی	گروه‌های صوت، موسیقی Google، موسیقی MiniMax و ویدئوهای A-D.

stable شامل native-live-src-gateway-profiles-anthropic-smoke و native-live-src-gateway-profiles-opencode-go-smoke است؛ full به‌جای آن‌ها از شاردهای گسترده‌تر مدل‌های Anthropic و OpenCode Go استفاده می‌کند. اجرای مجدد متمرکز همچنان می‌تواند از دستگیره‌های تجمیعی native-live-src-gateway-profiles-anthropic یا native-live-src-gateway-profiles-opencode-go استفاده کند.

اجرای مجدد متمرکز

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

دستگیره	دامنه
`all`	همهٔ مراحل اعتبارسنجی کامل انتشار.
`ci`	فقط گردش‌کار فرزند CI کامل دستی.
`plugin-prerelease`	فقط گردش‌کار فرزند پیش‌انتشار Plugin.
`release-checks`	همهٔ مراحل بررسی انتشار OpenClaw.
`install-smoke`	آزمون دود نصب تا پایان بررسی‌های انتشار.
`cross-os`	بررسی‌های انتشار میان‌سیستم‌عاملی.
`live-e2e`	اعتبارسنجی E2E مخزن/زنده و مسیر انتشار Docker.
`package`	پذیرش بسته.
`qa`	هم‌ارزی QA به‌علاوهٔ مسیرهای زندهٔ QA.
`qa-parity`	فقط مسیرها و گزارش هم‌ارزی QA.
`qa-live`	Matrix/Telegram زندهٔ QA به‌علاوهٔ مسیرهای مشروط Discord،‏ WhatsApp و Slack در صورت فعال‌بودن.
`npm-telegram`	E2E بستهٔ منتشرشده در Telegram؛ به `release_package_spec` یا `npm_telegram_package_spec` نیاز دارد.
`performance`	فقط شواهد عملکرد محصول.

وقتی یک مجموعهٔ زنده ناموفق است، از live_suite_filter همراه با rerun_group=live-e2e استفاده کنید. شناسه‌های معتبر فیلتر در گردش‌کار قابل‌استفادهٔ مجدد زنده/E2E تعریف شده‌اند، از جمله docker-live-models، live-gateway-docker، live-gateway-anthropic-docker، live-gateway-google-docker، live-gateway-minimax-docker، live-gateway-advisory-docker، live-cli-backend-docker، live-acp-bind-docker و live-codex-harness-docker.

دستگیرهٔ live-gateway-advisory-docker یک دستگیرهٔ اجرای مجدد تجمیعی برای سه شارد ارائه‌دهندهٔ خود است؛ بنابراین همچنان به همهٔ کارهای مشورتی Gateway در Docker منشعب می‌شود.

وقتی یک مسیر میان‌سیستم‌عاملی ناموفق است، از cross_os_suite_filter همراه با rerun_group=cross-os استفاده کنید. فیلتر یک شناسهٔ سیستم‌عامل، شناسهٔ مجموعه یا جفت سیستم‌عامل/مجموعه را می‌پذیرد؛ برای نمونه windows/packaged-upgrade،‏ windows یا packaged-fresh. خلاصه‌های میان‌سیستم‌عاملی شامل زمان‌بندی هر مرحله برای مسیرهای ارتقای بسته‌بندی‌شده هستند و فرمان‌های طولانی‌مدت خطوط Heartbeat چاپ می‌کنند تا به‌روزرسانی گیرکرده پیش از پایان مهلت کار قابل‌مشاهده باشد.

شکست بررسی‌های انتشار QA، اعتبارسنجی عادی انتشار را مسدود می‌کند. بررسی پوشش ابزار زمان اجرای QA (انحراف پویای ابزار میان openclaw و codex در سطح استاندارد) نیز اعتبارسنج بررسی انتشار را مسدود می‌کند، هرچند مسیر زیربنایی هم‌ارزی زمان اجرای QA مشورتی است. اجراهای آلفای Tideclaw همچنان می‌توانند مسیرهای بررسی انتشارِ غیرمرتبط با ایمنی بسته را مشورتی در نظر بگیرند. با release_profile=beta، مجموعه‌های ارائه‌دهندهٔ زندهٔ Run repo/live E2E validation مشورتی هستند: استقرارهای مدل شخص ثالث در زیرساخت انتشار تغییر می‌کنند، بنابراین بتا شکست‌های آن‌ها را به‌شکل هشدار نمایش می‌دهد، درحالی‌که پروفایل‌های پایدار و کامل آن‌ها را مسدودکننده نگه می‌دارند. وقتی live_suite_filter صراحتاً یک مسیر زندهٔ مشروط QA مانند Discord، WhatsApp یا Slack را درخواست می‌کند، متغیر مخزن متناظر OPENCLAW_RELEASE_QA_*_LIVE_CI_ENABLED باید فعال باشد؛ در غیر این صورت، ثبت ورودی به‌جای نادیده‌گرفتن بی‌سروصدای مسیر ناموفق می‌شود. وقتی به شواهد تازهٔ QA نیاز دارید، rerun_group=qa،‏ qa-parity یا qa-live را دوباره اجرا کنید.

شواهدی که باید نگه دارید

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

مصنوعات مفید:

release-package-under-test از OpenClaw Release Checks
مصنوعات مسیر انتشار Docker در .artifacts/docker-tests/
مصنوعات package-under-test پذیرش بسته و پذیرش Docker
مصنوعات بررسی انتشار میان‌سیستم‌عاملی برای هر سیستم‌عامل و مجموعه
مصنوعات هم‌ارزی QA، هم‌ارزی زمان اجرا، Matrix و Telegram

فایل‌های گردش‌کار

.github/workflows/full-release-validation.yml
.github/workflows/openclaw-release-checks.yml
.github/workflows/openclaw-live-and-e2e-checks-reusable.yml
.github/workflows/plugin-prerelease.yml
.github/workflows/install-smoke.yml
.github/workflows/install-smoke-reusable.yml
.github/workflows/openclaw-cross-os-release-checks-reusable.yml
.github/workflows/package-acceptance.yml
.github/workflows/openclaw-performance.yml
.github/workflows/npm-telegram-beta-e2e.yml

Was this useful?