پایپ‌لاین CI

CI در OpenClaw هنگام push به main (مسیرهای Markdown و docs/** در راه‌انداز نادیده گرفته می‌شوند)، برای هر pull request غیرپیش‌نویس، و هنگام اجرای دستی اجرا می‌شود. pushهای متعارف main به‌صورت تک‌اجرا هستند: گروه هم‌زمانی CI اجازه می‌دهد یک چرخه کامل یکپارچه‌سازی اجرا شود، درحالی‌که GitHub فقط جدیدترین push در انتظار را نگه می‌دارد. ادغام‌های جدید به‌جای لغو کاری که از قبل یک ماتریس Blacksmith ثبت کرده است، جایگزین آن اجرای در انتظار می‌شوند. pull requestها همچنان headهای منسوخ‌شده را لغو می‌کنند و اجراهای دستی از گروه‌های مجزا استفاده می‌کنند. preflight تفاوت‌ها را دسته‌بندی می‌کند و هنگامی که فقط نواحی نامرتبط تغییر کرده‌اند، laneهای پرهزینه را غیرفعال می‌کند. اجراهای دستی workflow_dispatch عمداً محدوده‌بندی هوشمند را دور می‌زنند و برای نامزدهای انتشار و اعتبارسنجی گسترده، کل گراف را به‌صورت موازی اجرا می‌کنند. laneهای Android از طریق include_android (یا ورودی release_gate) همچنان انتخابی باقی می‌مانند. پوشش Plugin ویژه انتشار در گردش‌کار جداگانه Plugin Prerelease قرار دارد و فقط از Full Release Validation یا یک اجرای دستی صریح اجرا می‌شود.

نمای کلی پایپ‌لاین

گردش‌کارهای مستقل Periphery نبود یافته‌های کد مرده را برای برنامه‌های iOS و macOS الزامی می‌کنند. گردش‌کار مشترک OpenClawKit هر دو مصرف‌کننده را به‌صورت موازی اسکن می‌کند و فقط زمانی یک اعلان را گزارش می‌دهد که Periphery همان Swift USR را از هر دو ساخت منتشر کند. قرارداد schema تولیدشده آن، یعنی OpenClawProtocol/GatewayModels.swift، به‌عنوان کد تحت مالکیت مولد نگه داشته می‌شود و کد مرده محلی برنامه محسوب نمی‌شود.

ترتیب توقف سریع

1. preflight تعیین می‌کند که اساساً کدام laneها وجود داشته باشند. منطق docs-scope و changed-scope گام‌هایی درون این کار هستند، نه کارهای مستقل. main متعارف بلافاصله آغاز می‌شود، اما گروه هم‌زمانی آن فقط یک اجرای کامل را می‌پذیرد و pushهای بعدی را در یک جدیدترین اجرای در انتظار ادغام می‌کند. pushهای main مرتبط با Node همچنین تنها نویسنده دیسک وابستگی‌ها و نگهداری اندازه آن را در اینجا به‌صورت ترتیبی اجرا می‌کنند، پیش از آنکه کارهای پایین‌دستی بتوانند کلید را mount کنند؛ Blacksmith ممکن است یک commit تازه را فقط در اجرای بعدی گردش‌کار نمایان کند، بنابراین مصرف‌کنندگان همان اجرا راهکار جایگزین محلی با بررسی نشانگر را حفظ می‌کنند.
2. security-fast، check-*، check-additional-*، check-docs و skills-python بدون انتظار برای کارهای سنگین‌تر ماتریس artifact و پلتفرم، سریع شکست می‌خورند.
3. build-artifacts و بررسی‌های locale هم‌زمان با laneهای سریع Linux اجرا می‌شوند. PRهای منبع رابط کاربری Control و برنامه بومی، snapshotها/منابع locale تولیدشده را مستثنا می‌کنند؛ گردش‌کارهای تازه‌سازی ترتیبی آن‌ها PRهای تولیدشده مجزا را در پس‌زمینه اصلاح و به‌طور خودکار ادغام می‌کنند. CI منبع همچنان موجودی‌های منبع قدیمی و فراخوانی‌های ناامن محلی‌سازی را مسدود می‌کند. PRهای تولیدشده، CI دستی و آماده‌سازی انتشار، برابری کامل ترجمه‌ها/خروجی تولیدشده پلتفرم را الزامی می‌کنند. شاخه‌های متعارف release/YYYY.M.PATCH ممکن است اصلاحات locale آماده‌سازی انتشار را همراه دیگر خروجی‌های تولیدشده انتشار شامل شوند.
4. پس از آن، laneهای سنگین‌تر پلتفرم و زمان اجرا به‌صورت موازی اجرا می‌شوند: checks-fast-core، checks-fast-contracts-plugins-*، checks-fast-contracts-channels-*، checks-node-*، checks-windows، macos-node، macos-swift، ios-build و android.
5. openclaw/ci-gate منتظر تمام laneهای انتخاب‌شده می‌ماند. پیش‌بررسی و امنیت باید موفق شوند؛ کارهای پایین‌دستی فقط زمانی می‌توانند نادیده گرفته شوند که مانیفست آن‌ها را انتخاب نکرده باشد. شکست یا لغو یک lane انتخاب‌شده باعث شکست تجمیع می‌شود.

هماهنگ‌کننده ادغام می‌تواند یک openclaw/ci-gate موفق و احراز هویت‌شده را برای همان head از pull request تا حداکثر 24 ساعت دوباره استفاده کند. این کار از بازنویسی شاخه مشارکت‌کننده پس از تغییرات نامرتبط main جلوگیری می‌کند. نتیجه قابل‌استفاده مجدد جایگزین بررسی جداگانه و سخت‌گیرانه ادغام آزمایشی تحت مالکیت App در برابر main فعلی نمی‌شود. اجرای مجدد در انتظار یا ناموفق بعدی، نتیجه موفق قبلی را برای آن head بدون تغییر در بازه تازگی پاک نمی‌کند.

مجموعه‌قوانین شاخه پیش‌فرض، بررسی openclaw/ci-gate متعلق به GitHub Actions را الزامی می‌کند. نگه‌دارندگان و مدیران مخزن یک سازوکار عبور اضطراریِ حسابرسی‌شده دارند که فقط برای فرودهای مستقیم، امضاشده و fast-forward در نظر گرفته شده است؛ مجموعه‌قوانین سازمان همچنان حذف و به‌روزرسانی‌های non-fast-forward را مسدود می‌کند. ادغام‌های عادی Pull request باید به‌جای دور زدن CI ناموفق، همچنان از این دروازه استفاده کنند. بررسی سخت‌گیرانه و جداگانه test-merge متعلق به App نیز همچنان head را به main فعلی مقید می‌کند.

وقتی head جدیدتری فرود می‌آید، GitHub ممکن است کارهای جایگزین‌شده Pull request را با وضعیت cancelled علامت‌گذاری کند. مگر اینکه جدیدترین اجرا برای همان PR نیز ناموفق باشد، آن را نویز CI در نظر بگیرید. اجراهای متعارف main پس از پذیرش لغو نمی‌شوند؛ هنگامی که ترافیک ادغام می‌رسد، GitHub فقط اجرای قدیمی‌ترِ در انتظار را با جدیدترین tip جایگزین می‌کند. کارهای ماتریسی از fail-fast: false استفاده می‌کنند و build-artifacts شکست‌های کانال تعبیه‌شده، مرز پشتیبانی هسته و پایش Gateway را مستقیماً گزارش می‌کند، نه اینکه کارهای کوچک تأییدکننده را در صف قرار دهد. کلید هم‌زمانی خودکار CI نسخه‌بندی شده است (CI-v7-*) تا یک اجرای زامبی در سمت GitHub و در یک گروه صف قدیمی نتواند اجراهای جدیدتر main را برای مدتی نامحدود مسدود کند. اجراهای دستی مجموعه کامل از CI-manual-v1-* استفاده می‌کنند و اجراهای در حال انجام را لغو نمی‌کنند. محافظ حافظه راه‌اندازی فهرست Plugin، سقف 350 MiB را در Linux خودمیزبان Blacksmith حفظ می‌کند و در Linux میزبانی‌شده توسط GitHub مقدار 425 MiB را مجاز می‌داند، زیرا خط مبنای RSS آن برای همان CLI ساخته‌شده بالاتر است.

برای خلاصه‌کردن زمان سپری‌شده، زمان صف، کندترین کارها، شکست‌ها و مانع fanout مربوط به pnpm-store-warmup از GitHub Actions، از pnpm ci:timings، pnpm ci:timings:recent یا node scripts/ci-run-timings.mjs <run-id> استفاده کنید. کار ci-timings-summary درون گردش‌کار در ci.yml وجود دارد، اما در حال حاضر غیرفعال است (if: false)؛ در عوض، ابزار کمکی زمان‌بندی را به‌صورت محلی اجرا کنید. برای زمان‌بندی ساخت، مرحله Build dist از کار build-artifacts را بررسی کنید: pnpm build:ci-artifacts مقدار [build-all] phase timings: را چاپ می‌کند و شامل ui:build است؛ این کار همچنین artifact مربوط به startup-memory را بارگذاری می‌کند.

زمینه و شواهد PR

PRهای مشارکت‌کنندگان خارجی، دروازه زمینه و شواهد PR را از .github/workflows/real-behavior-proof.yml اجرا می‌کنند. گردش‌کار، بازبینی مورد اعتماد گردش‌کار (github.workflow_sha) را checkout می‌کند و فقط بدنه PR را ارزیابی می‌کند؛ هیچ کدی از شاخه مشارکت‌کننده اجرا نمی‌کند.

این دروازه برای نویسندگان PR که مالک، عضو، همکار یا ربات مخزن نیستند اعمال می‌شود. وقتی بدنه PR شامل بخش‌های تألیف‌شده What Problem This Solves و Evidence باشد، بررسی موفق می‌شود. شواهد می‌تواند یک آزمون متمرکز، نتیجه CI، اسکرین‌شات، ضبط، خروجی ترمینال، مشاهده زنده، گزارش حذف‌شده اطلاعات حساس یا پیوند artifact باشد. بدنه، هدف و اعتبارسنجی مفید را ارائه می‌کند؛ بازبینان برای ارزیابی درستی، کد، آزمون‌ها و CI را بررسی می‌کنند.

وقتی بررسی ناموفق است، به‌جای push کردن یک commit کد دیگر، بدنه PR را به‌روزرسانی کنید.

دامنه و مسیریابی

منطق دامنه در scripts/ci-changed-scope.mjs قرار دارد و آزمون‌های واحد در src/scripts/ci-changed-scope.test.ts آن را پوشش می‌دهند. اجرای دستی، تشخیص دامنه تغییریافته را نادیده می‌گیرد و باعث می‌شود مانیفست پیش‌بررسی چنان عمل کند که گویی همه نواحی دامنه‌بندی‌شده تغییر کرده‌اند.

گردش‌کارهای جداگانه Periphery برای iOS و macOS، سیاست کد مرده با صفر یافته را اعمال می‌کنند. هرکدام فقط زمانی اجرا می‌شوند که یک Pull request غیرا‌پیش‌نویس دامنه اسکن بومی آن را تغییر دهد، یا به‌صورت دستی اجرا شود.

• ویرایش‌های گردش‌کار CI گراف Node در CI، lint گردش‌کار و lane ویندوز را اعتبارسنجی می‌کنند (ci.yml آن را اجرا می‌کند)، اما به‌تنهایی ساخت‌های بومی iOS، Android یا macOS را اجباری نمی‌کنند؛ آن laneهای پلتفرمی همچنان به تغییرات منبع همان پلتفرم محدود می‌مانند.
• سلامت گردش‌کار، actionlint، zizmor را روی همه فایل‌های YAML گردش‌کار، محافظ درون‌یابی composite-action و محافظ نشانگر تعارض اجرا می‌کند. کار محدود به PR با نام security-fast نیز zizmor را روی فایل‌های تغییریافته گردش‌کار اجرا می‌کند تا یافته‌های امنیتی گردش‌کار در همان ابتدای گراف اصلی CI شکست ایجاد کنند.
• مستندات در pushهای main با گردش‌کار مستقل Docs و همان آینه مستندات ClawHub مورد استفاده CI بررسی می‌شوند، بنابراین pushهای ترکیبی کد+مستندات، shard مربوط به check-docs در CI را نیز در صف قرار نمی‌دهند. Pull requestها و CI دستی، هنگام تغییر مستندات همچنان check-docs را از CI اجرا می‌کنند.
• PTY در TUI برای تغییرات TUI در shard مربوط به Linux Node با نام checks-node-core-runtime-tui-pty اجرا می‌شود. این shard، test/vitest/vitest.tui-pty.config.ts را با OPENCLAW_TUI_PTY_INCLUDE_LOCAL=1 اجرا می‌کند، بنابراین هم lane قطعی fixture با نام TuiBackend و هم smoke کندتر tui --local را پوشش می‌دهد که فقط endpoint مدل خارجی را شبیه‌سازی می‌کند.
• ویرایش‌های صرفاً مسیریابی CI، مجموعه کوچک fixtureهای آزمون هسته که وظیفه سریع مستقیماً اجرا می‌کند و ویرایش‌های محدود ابزارهای کمکی قرارداد Plugin از یک مسیر مانیفست سریع و صرفاً Node استفاده می‌کنند: preflight، security-fast و فقط laneهای سریعی که تغییر با آن‌ها تماس دارد — یک وظیفه مسیریابی CI با نام checks-fast-core، دو shard قرارداد Plugin یا هر دو. این مسیر artifactهای ساخت، سازگاری Node 22، قراردادهای کانال، shardهای کامل هسته، shardهای Pluginهای همراه و ماتریس‌های محافظ اضافی را نادیده می‌گیرد.
• بررسی‌های Node ویندوز به wrapperهای فرایند/مسیر مختص ویندوز، ابزارهای کمکی اجراکننده npm/pnpm/UI، پیکربندی مدیر بسته و سطوح گردش‌کار CI که آن lane را اجرا می‌کنند محدود هستند؛ تغییرات نامرتبط منبع، Plugin، smoke نصب و تغییرات صرفاً آزمون در laneهای Linux Node باقی می‌مانند.

کندترین خانواده‌های آزمون Node تقسیم یا متعادل شده‌اند تا هر کار بدون رزرو بیش‌ازحد اجراکننده‌ها کوچک باقی بماند:

• قراردادهای Plugin و قراردادهای کانال، هرکدام به‌صورت دو شارد وزن‌دهی‌شده با پشتیبانی Blacksmith و با راهکار جایگزین استاندارد رانر GitHub اجرا می‌شوند.
• لاین‌های سریع/پشتیبانی آزمون واحد هسته جداگانه اجرا می‌شوند؛ زیرساخت زمان‌اجرای هسته به شاردهای فرایند، مشترک، هوک‌ها، اسرار و سه دامنه Cron تقسیم می‌شود.
• پاسخ خودکار به‌صورت ورکرهای متوازن اجرا می‌شود و زیردرخت پاسخ به شاردهای اجراکننده عامل، فرمان‌ها، توزیع، نشست و مسیریابی وضعیت تقسیم می‌شود.
• پیکربندی‌های Gateway/سرور عامل‌محور (صفحه کنترل) به‌جای انتظار برای مصنوعات ساخته‌شده، میان لاین‌های چت، احراز هویت، مدل، HTTP/Plugin، زمان‌اجرا و راه‌اندازی تقسیم می‌شوند.
• پایپ‌لاین CI عادی فقط شاردهای الگوی include زیرساخت ایزوله را در بسته‌های قطعیِ حداکثر 64 فایل آزمون بسته‌بندی می‌کند و بدون ادغام مجموعه‌های غیرایزوله فرمان/Cron، agents-core وضعیت‌دار یا Gateway/سرور، ماتریس Node را کاهش می‌دهد. مجموعه‌های ثابت سنگین روی 8 vCPU باقی می‌مانند، درحالی‌که لاین‌های بسته‌بندی‌شده و سبک‌تر از 4 vCPU استفاده می‌کنند.
• Pull requestهای مخزن متعارف، حل‌کننده آزمون‌های تغییریافته را در برابر تفاوت درخت ادغام‌شده مصنوعی دوباره به‌کار می‌گیرند. تغییرات دقیق یک کار هدفمند Node را اجرا می‌کنند؛ هر فایل آزمون انتخاب‌شده فرایند خودش را دریافت می‌کند تا ایزولاسیون مجموعه وضعیت‌دار دست‌نخورده بماند. برنامه‌ریز، آزمون‌های هم‌سطح را با وابسته‌های گراف واردسازی ترکیب می‌کند و برای تغییرات بسته فضای کاری، بسته/فایل قفل، هارنس مشترک، پیکربندی تقسیم‌شده، تغییرنام‌یافته یا حذف‌شده، تغییرات عمومی قرارداد افزونه، آزمون‌های دارای تنظیم ویژه شارد، اهداف ناقص حل‌شده یا خالی، برنامه‌های مسیر یا هدف بیش‌ازحد بزرگ و خطاهای برنامه‌ریز، به برنامه فشرده موجودِ مجموعه کامل با 14 کار بازمی‌گردد. برنامه‌های هدفمند همیشه گیت کامل مرز مصنوعات ساخته‌شده را حفظ می‌کنند، زیرا اسکنرهای مخزن آن را نمی‌توان از واردسازی‌ها استخراج کرد. اجراهای main همان مجموعه فشرده کامل را اجرا می‌کنند: رویدادهای push میانیِ در انتظار ممکن است با هم ادغام شوند، بنابراین جدیدترین اجرای باقی‌مانده باید به‌جای صرفاً تفاوت آخرین push منفرد خود، کل درخت یکپارچه‌سازی را اعتبارسنجی کند. اجراهای دستی و گیت‌های انتشار، ماتریس کامل نام‌گذاری‌شده برای هر شارد را حفظ می‌کنند.
• ماتریس کامل Node ابتدا ابزارهای سریالیِ همواره کند، شاردهای فرمان پاسخ خودکار و نویسنده گسترده کش core-fast را می‌پذیرد. این کار سقف 28 کار را حفظ می‌کند و هم‌زمان مانع از آن می‌شود که کارهای مسیر بحرانی و بذر تبدیل اجرای بعدی به موجی دیرتر منتقل شوند.
• آزمون‌های گسترده مرورگر، QA، رسانه و Pluginهای متفرقه، به‌جای catch-all مشترک Plugin از پیکربندی‌های اختصاصی Vitest خود استفاده می‌کنند. شاردهای الگوی include، ورودی‌های زمان‌بندی را با نام شارد CI ثبت می‌کنند تا .artifacts/vitest-shard-timings.json بتواند یک پیکربندی کامل را از یک شارد فیلترشده تشخیص دهد.
• کارهای شارد Linux Node، کش آزمایشی ماژول فایل‌سیستمی Vitest را از طریق API بالادستی کش Actions ماندگار می‌کنند؛ Blacksmith این کش را روی رانرهای خود به‌طور شفاف شتاب می‌دهد. هر شارد CI فقط بازیابی می‌کند و بذر محافظت‌شده را در ریشه محلی مخصوص همان رانر باز می‌کند؛ سپس لفاف شارد به فرایندهای هم‌زمان Vitest زیردایرکتوری‌های فعال جداگانه می‌دهد. فقط گرم‌کننده روزانه لغونشدنی یا گرم‌کننده‌ای که صراحتاً اجرا شده باشد، یک آرشیو تغییرناپذیر جدید ذخیره می‌کند؛ بنابراین Pull requestها نمی‌توانند تبدیل‌ها را منتشر کنند یا خانواده‌های کش مختص هر PR بسازند. اثرانگشت ورودی تبدیل، نسل‌های ناسازگار فایل قفل، بسته، tsconfig و پیکربندی Vitest را پاک می‌کند. نویسنده محافظت‌شده، پس از عبور کش بازیابی‌شده از 2 GiB، آن را اسکن می‌کند و تا 75% هرس می‌کند. Vitest شناسه ماژول، محتوای منبع، محیط و پیکربندی تبدیل حل‌شده را هش می‌کند؛ بنابراین تغییرات جزئی عادی منبع، ورودی‌های تغییریافته‌نشده را گرم نگه می‌دارند و ماژول‌های تغییریافته با ایمنی cache miss می‌شوند. پیشوندهای بازیابی درشت‌دانه میان اجراهای گردش‌کار پل می‌زنند؛ LRU عادی کش Actions و حذف بر پایه عدم‌فعالیت، آرشیوهای تغییرناپذیر قدیمی را محدود می‌کنند.
• کارهای مورداعتماد Linux Node همچنین فروشگاه pnpm و node_modules را از یک دیسک وابستگی محافظت‌شده برای هر خط پشتیبانی‌شده Node متصل می‌کنند. مانیفست‌های بسته، تنظیمات نصب، پلتفرم رانر و نسخه دقیق اصلاحی Node در کلید دیسک وارد نمی‌شوند؛ یک اثرانگشت دقیق زمان‌اجرا و ورودی نصب تعیین می‌کند که کار، درخت را دوباره به‌کار گیرد یا مجدداً نصب و همان دیسک را نوسازی کند. مانیفست‌ها پیش از هش‌کردن متعارف‌سازی می‌شوند. هوک‌های مستقیم ریشه که ممیزی شده‌اند فقط اسکریپت‌های چرخه‌عمر نصب pnpm را نگه می‌دارند، بنابراین ویرایش‌های قالب‌بندی و اسکریپت‌های عادی آزمون/ساخت، درخت وابستگی گرم را حفظ می‌کنند؛ تغییر ممیزی‌نشده هوک چرخه‌عمر تا زمانی که ورودی‌های منبع آن به قرارداد اثرانگشت ملحق شوند، به‌صورت بسته شکست می‌خورد. تغییرات وابستگی، مدیر بسته، منبع هوک و فایل قفل همیشه snapshot را نامعتبر می‌کنند. تطابق اثرانگشت لازم است اما کافی نیست: راه‌اندازی همچنین آرشیو importer و checksum مانیفست‌ها را بررسی می‌کند، سپس تأیید می‌کند که وابستگی‌های فایل قفل متکی به رجیستری که postinstall نگه داشته است، با مانیفست بسته‌هایی که Node از importerهایشان حل می‌کند مطابقت دارند. محتوای importer گم‌شده یا کهنه به‌جای ارائه hoist ریشه، به نصب تازه بازمی‌گردد. Pull requestی که snapshot فقط‌خواندنی آن قابل‌استفاده نیست، اتصال فضای کاری را جدا می‌کند و در فضای ذخیره‌سازی محلی رانر نصب می‌کند تا از نوشتن کند در cloneای که نمی‌تواند منتشر کند جلوگیری شود. نصب‌های سرد دیسک چسبنده، تلاش‌های مجدد داخلی fetch در pnpm را غیرفعال می‌کنند و حداکثر سه تلاش کامل نصب محدودشده را از فروشگاه به‌تدریج گرم‌شده انجام می‌دهند؛ timeout همچنان شکست محسوب می‌شود. پس از بازیابی اعتبارسنجی‌شده از نظر محتوا یا نصب frozen-lockfile، راه‌اندازی بررسی تکراری وابستگی پیش از اجرا در pnpm را غیرفعال می‌کند: مخزن عمداً node_modules محلی Plugin را هرس می‌کند که pnpm در غیر این صورت آن را کهنه تلقی می‌کند و طی fanout شارد از طریق نصب‌های ضمنی هم‌زمان ناامن تعمیر می‌کند. پیش‌بررسی متعارف main تنها نویسنده است و در هر نوسازی، فروشگاه را اندازه‌گیری می‌کند و فقط پس از آنکه نسخه‌های بازنشسته بسته حجم آن را از 8 GiB عبور دهند، pnpm store prune را اجرا می‌کند. انتشار snapshot در Blacksmith حتی پس از تکمیل کار نویسنده ناهمگام است، بنابراین نخستین اجرا پس از یک کلید یا اثرانگشت تازه ممکن است همچنان سرد بماند؛ بازیابی‌های بعدی exact-marker که محتوایشان اعتبارسنجی شده، مدرک استقرار تدریجی هستند. کارهای الزامی CI و Pull requestها cloneهای یک‌بارمصرف دریافت می‌کنند، بنابراین تغییرات وابستگی دیسک‌های جدید، snapshotهای رقیب یا قفل کشی که بتواند ساخت‌ها را لغو کند ایجاد نمی‌کنند.
• کارهای شارد Node و مصنوعات ساخت نیز کش قابل‌حمل کامپایل روی دیسک Node را از طریق کش‌های تغییرناپذیر Actions بازیابی می‌کنند. فضای نام‌های مستقل test و build مانع جایگزینی آرشیوهای یکدیگر توسط نویسندگانشان می‌شوند: گرم‌کننده زمان‌بندی‌شده آزمون مالک بذر محافظت‌شده آزمون است، درحالی‌که build-artifacts می‌تواند در هر روز UTC حداکثر یک آرشیو ساخت محافظت‌شده از pushهای مورداعتماد main منتشر کند. کارهای PR و آزمون عادی فقط snapshotهای محافظت‌شده را می‌خوانند، بنابراین بایت‌کد شاخه ویژگی هرگز وارد بذر مشترک نمی‌شود و ترافیک PR هیچ آرشیو کشی ایجاد نمی‌کند. این سازوکار بایت‌کد V8 را برای هماهنگ‌سازی بارگذاری‌شده توسط Node، ابزارهای ساخت و وابستگی‌های خارجی در مسیرهای checkout متفاوت، از جمله زمانی که فقط بخشی از گراف منبع تغییر می‌کند، دوباره به‌کار می‌گیرد. فرایندهای فرزند Vitest کش کامپایل به‌ارث‌رسیده را غیرفعال می‌کنند، زیرا پوشش ممکن است درون پیکربندی‌های پویا فعال شود و پوشش V8 هنگام deserialize شدن اسکریپت‌ها از بایت‌کد ممکن است دقت موقعیت منبع را از دست بدهد.
• کار مصنوعات ساخت همچنین خروجی مراحل build-all با اثرانگشت محتوا را ماندگار می‌کند. اعلان‌های Plugin SDK که خود CI می‌سازد، کل گراف منبع TypeScript/JSON تحت مالکیت مخزن را هش می‌کنند، دایرکتوری‌های نصب‌شده و تولیدشده را کنار می‌گذارند و پس از آنکه tsdown، dist را پاک می‌کند، هم اعلان‌های تخت و هم پل‌های بسته را بازیابی می‌کنند. تغییرات مستندات، گردش‌کار، Plugin و سایر تغییرات بیرون از آن گراف می‌توانند snapshot اعلان را دوباره به‌کار گیرند؛ تغییرات منبع پیش از اجرای گیت export آن را دوباره می‌سازند.
• ساخت‌های کامل اعلان، tsdown را به گروه‌های AI، بسته فضای کاری و یکپارچه تقسیم می‌کنند. هر گروه فقط اعلان‌ها را کش می‌کند و سپس همچنان JavaScript زمان‌اجرا را پیش از بازیابی آن اعلان‌ها دوباره می‌سازد. بنابراین تغییرات هسته یا Plugin فقط گراف بزرگ یکپارچه را نامعتبر می‌کنند، درحالی‌که تغییرات بسته فضای کاری به‌صورت محافظه‌کارانه تمام گروه‌های اعلان وابسته را نامعتبر می‌کنند. ساخت‌های کامل عمومی عموماً از کش تغییرناپذیر Actions استفاده می‌کنند؛ کلیدهای بازیابی درشت‌دانه تغییرات جزئی را بذرگذاری می‌کنند، اثرانگشت‌های محتوای هر گروه داده‌های کهنه را رد می‌کنند و سهمیه کش GitHub نسل‌های قدیمی را حذف می‌کند. در عوض، لاین هفتگی Node 22 پس از اجرای موفق main یک artifact با ماندگاری 14 روز منتشر می‌کند و فقط artifactهایی را بازیابی می‌کند که هویت تغییرناپذیر تولیدکننده‌شان در main به آن گردش‌کار حل شود؛ بدین‌ترتیب بدون اجازه‌دادن به کد PR برای نوشتن کش مشترک، از نوسان سهمیه جلوگیری می‌شود. اعلان‌های Private-QA هرگز در کش‌های Actions ماندگار نمی‌شوند، زیرا فضای نام کش مرز محرمانگی نیست.
• check-additional-* فهرست تکمیلی نگهبان مرزی (scripts/run-additional-boundary-checks.mjs) را به یک شارد سنگین از نظر prompt (check-additional-boundaries-a، شامل بررسی انحراف snapshot پرامپت Codex) و یک شارد ترکیبی برای نوارهای باقی‌مانده (check-additional-boundaries-bcd) تقسیم نواری می‌کند؛ هرکدام نگهبان‌های مستقل را هم‌زمان اجرا می‌کنند و زمان‌بندی هر بررسی را چاپ می‌کنند. کار کامپایل/canary مرز بسته در کنار هم باقی می‌ماند و معماری توپولوژی زمان‌اجرا جدا از پوشش نظارت Gateway تعبیه‌شده در build-artifacts اجرا می‌شود.
• روی رانر ساخت self-hosted با 32-vCPU، نظارت Gateway، آزمون‌های کانال و شارد مرز پشتیبانی هسته پس از آنکه dist/ و dist-runtime/ از قبل ساخته شده‌اند، با هم درون build-artifacts آغاز می‌شوند. اجراهای جایگزین GitHub-hosted، نظارت Gateway را سریالی نگه می‌دارند تا رقابت بر سر هسته‌های کم نتواند مهلت آمادگی آن را مصرف کند.

پس از پذیرش، CI متعارف Linux حداکثر 28 کار آزمون Node هم‌زمان و 12 کار برای لاین‌های کوچک‌تر سریع/بررسی مجاز می‌داند؛ Windows و Android روی دو باقی می‌مانند، زیرا pool رانرهای آن‌ها محدودتر است. دسته‌های فشرده پیکربندی کامل با timeout دسته‌ای 120 دقیقه‌ای اجرا می‌شوند، درحالی‌که گروه‌های الگوی include همان بودجه محدود کار را به‌اشتراک می‌گذارند.

CI مربوط به Android هم testPlayDebugUnitTest و هم testThirdPartyDebugUnitTest را اجرا می‌کند و سپس APK اشکال‌زدایی Play را می‌سازد. flavor شخص ثالث source set یا مانیفست جداگانه‌ای ندارد؛ لاین آزمون واحد آن همچنان flavor را با پرچم‌های BuildConfig مربوط به SMS/call-log کامپایل می‌کند، درحالی‌که از ایجاد کار تکراری بسته‌بندی APK اشکال‌زدایی در هر push مرتبط با Android جلوگیری می‌کند. هر وظیفه کنونی Gradle یک دیسک چسبنده محافظت‌شده دارد؛ کارهای PR از cloneهای یک‌بارمصرف استفاده می‌کنند، درحالی‌که اجراهای محافظت‌شده ورودی‌های Gradle با آدرس‌دهی محتوایی را درجا نوسازی می‌کنند.

کلیدهای دیسک چسبنده Blacksmith عمداً فقط با ابعاد زمان‌اجرا یا وظیفه پشتیبانی‌شده محدود می‌شوند و هرگز شامل شماره PR، commit، اجرا، شاخه یا هش وابستگی نیستند. کش‌های تبدیل و کامپایل زمان‌اجرا به‌جای دیسک‌های چسبنده از کش Actions استفاده می‌کنند، زیرا آرشیوهای تغییرناپذیر نتایج قابل‌تأیید بازیابی/ذخیره را آشکار می‌کنند و از شکست‌های ارتقای snapshot تغییرپذیر جلوگیری می‌کنند. پس از مهاجرت نسخه کلید چسبنده، فقط هویت‌های دقیق کلید، معماری و منطقه منسوخ را به .github/retired-sticky-disks.json اضافه کنید، Sticky Disk Cleanup را از main با همان ابعاد و تأیید اجرا کنید، حذف را راستی‌آزمایی کنید و سپس آن ورودی‌ها را بردارید. گردش‌کار هویت‌های ARM را به رانر ARM هدایت می‌کند، ناسازگاری منطقه رانر را رد می‌کند، از action حذف با کلید دقیق Blacksmith استفاده می‌کند و هرگز کش‌های سازنده Docker یا پیشوندهای wildcard را حذف نمی‌کند. آرشیوهای کش Actions از LRU عادی و حذف بر پایه عدم‌فعالیت استفاده می‌کنند.

شارد check-dependencies بررسی‌های تولیدی Knip برای وابستگی، فایل استفاده‌نشده و export استفاده‌نشده را اجرا می‌کند. نگهبان فایل استفاده‌نشده هنگامی شکست می‌خورد که PR یک فایل استفاده‌نشده جدید و بازبینی‌نشده اضافه کند یا یک ورودی کهنه در allowlist باقی بگذارد، درحالی‌که سطوح عمدی Plugin پویا، تولیدشده، ساخت، آزمون زنده و پل بسته را که Knip نمی‌تواند به‌صورت ایستا حل کند حفظ می‌کند. نگهبان export استفاده‌نشده فایل‌های پشتیبانی آزمون را کنار می‌گذارد و برای هر export تولیدی استفاده‌نشده شکست می‌خورد؛ مصرف‌کنندگان پویای عمدی باید در config/knip.config.ts مدل‌سازی شوند. اهداف تاریخی در صورت ارائه این نگهبان، آن را اجرا می‌کنند و در غیر این صورت راهکار جایگزین قدیمی‌تر خود برای کد مرده را حفظ می‌کنند.

هدایت فعالیت ClawSweeper

.github/workflows/clawsweeper-dispatch.yml پل سمت مقصد از فعالیت مخزن OpenClaw به ClawSweeper است. این پل کد نامطمئن Pull request را checkout یا اجرا نمی‌کند. گردش‌کار با استفاده از CLAWSWEEPER_APP_PRIVATE_KEY یک توکن GitHub App ایجاد می‌کند و سپس payloadهای فشردهٔ repository_dispatch را به openclaw/clawsweeper ارسال می‌کند.

این گردش‌کار چهار مسیر دارد:

• clawsweeper_item برای درخواست‌های دقیق بازبینی issue و Pull request؛
• clawsweeper_comment برای فرمان‌های صریح ClawSweeper در نظرهای issue؛
• clawsweeper_commit_review برای درخواست‌های بازبینی در سطح commit در pushهای main؛
• github_activity برای فعالیت عمومی GitHub که عامل ClawSweeper ممکن است بررسی کند.

مسیر github_activity فقط فرادادهٔ نرمال‌شده را ارسال می‌کند: نوع رویداد، اقدام، کنشگر، مخزن، شمارهٔ مورد، URL، عنوان، وضعیت، و در صورت وجود، گزیده‌های کوتاه از نظرها یا بازبینی‌ها. این مسیر عمداً از ارسال کامل بدنهٔ Webhook خودداری می‌کند. گردش‌کار دریافت‌کننده در openclaw/clawsweeper، همان .github/workflows/github-activity.yml است که رویداد نرمال‌شده را برای عامل ClawSweeper به hook متعلق به OpenClaw Gateway ارسال می‌کند.

فعالیت عمومی برای مشاهده است، نه تحویل پیش‌فرض. عامل ClawSweeper مقصد Discord را در prompt خود دریافت می‌کند و فقط زمانی باید در #clawsweeper پست بگذارد که رویداد غیرمنتظره، اقدام‌پذیر، پرریسک یا از نظر عملیاتی مفید باشد. بازشدن‌ها و ویرایش‌های معمول، فعالیت‌های تکراری bot، نویز تکراری Webhook و ترافیک عادی بازبینی باید به NO_REPLY منجر شوند.

در سراسر این مسیر، عنوان‌ها، نظرها، بدنه‌ها، متن بازبینی، نام branchها و پیام‌های commit در GitHub را داده‌های نامطمئن در نظر بگیرید. آن‌ها ورودی تلخیص و ارزیابی اولیه‌اند، نه دستورالعمل‌هایی برای گردش‌کار یا runtime عامل.

اجرای دستی

اجرای دستی پایپ‌لاین CI همان گراف job پایپ‌لاین CI عادی را اجرا می‌کند، اما همهٔ مسیرهای محدوده‌بندی‌شدهٔ غیر Android را اجباری فعال می‌کند: shardهای Linux Node، shardهای Pluginهای همراه، shardهای قرارداد Plugin و کانال، سازگاری Node 22، check-*، check-additional-*، بررسی‌های smoke مصنوع ساخته‌شده، بررسی‌های مستندات، Skills پایتون، Windows، macOS، ساخت iOS و i18n رابط Control UI/برنامهٔ بومی. Pull requestهای خودکار منبع، موجودی استخراج بومی و ایمنی بومی‌سازی Android/Apple را بدون نیاز به خروجی ترجمه‌شده یا تولیدشده توسط پلتفرم در همان Pull request تأیید می‌کنند. گردش‌کار سریالی Native App Locale Refresh این مصنوعات را در یک Pull request ایزوله بازسازی می‌کند و پس از موفقیت بررسی‌های الزامی، ادغام خودکار exact-head را فعال می‌کند. برابری کامل بومی همچنان برای Pull requestهای مصنوعات تولیدشده، پایپ‌لاین CI دستی، Full Release Validation و آماده‌سازی انتشار مسدودکننده است. برابری locale در Control UI برای Pull requestهای خودکار و اجراهای main همچنان توصیه‌ای و برای پایپ‌لاین CI دستی/انتشار مسدودکننده است. اجرای مستقل و دستی پایپ‌لاین CI، Android را فقط با include_android=true اجرا می‌کند (ورودی release_gate نیز Android را اجباری می‌کند)؛ چتر کامل انتشار با ارسال include_android=true، Android را فعال می‌کند. بررسی‌های ایستای پیش‌انتشار Plugin، shard مختص انتشار agentic-plugins، پیمایش کامل دسته‌ای extensionها و مسیرهای Docker پیش‌انتشار Plugin از پایپ‌لاین CI مستثنا هستند. مجموعهٔ پیش‌انتشار Docker فقط زمانی اجرا می‌شود که Full Release Validation گردش‌کار جداگانهٔ Plugin Prerelease را با فعال‌بودن دروازهٔ اعتبارسنجی انتشار اجرا کند.

بررسی‌های حداکثر خطوط Pull request، خط مبنا را از درخت ادغام مصنوعی checkoutشده استخراج می‌کنند و والد head آن را در برابر head رویداد تأیید می‌کنند. اجراهای دستی از یک گروه هم‌زمانی منحصربه‌فرد استفاده می‌کنند تا مجموعهٔ کامل نامزد انتشار با push یا اجرای Pull request دیگری روی همان ref لغو نشود. ورودی اختیاری target_ref به یک فراخوانندهٔ مورداعتماد اجازه می‌دهد آن گراف را روی یک branch، tag یا SHA کامل commit اجرا کند، درحالی‌که از فایل گردش‌کار متعلق به ref اجرای انتخاب‌شده استفاده می‌شود؛ خط مبنای حداکثر خطوط با merge base هدف در برابر head شاخهٔ پیش‌فرض که برای آن اجرا resolve شده است مقایسه می‌شود. ورودی release_gate یک راهکار جایگزین exact-SHA برای نگه‌دارندگان در صورت توقف پایپ‌لاین CI مربوط به Pull request به‌دلیل ظرفیت است: این ورودی ایجاب می‌کند target_ref یک SHA کامل commit مطابق با head شاخهٔ اجراشده باشد و pull_request_number، Pull request بازی را مشخص کند که درخت ادغام آن اعتبارسنجی می‌شود.

gh workflow run ci.yml --ref release/YYYY.M.PATCHgh workflow run ci.yml --ref main -f target_ref=<branch-or-sha> -f include_android=truegh workflow run full-release-validation.yml --ref main -f ref=<branch-or-sha>

اجرای extended-stable مربوط به Gateway، پیش‌بررسی npm، Full Release Validation و انتشار npm مربوط به Plugin را از extended-stable/YYYY.M.33 اجرا می‌کند؛ انتشار هسته آن سه شناسهٔ اجرا را به‌همراه تلاش اعتبارسنجی مصرف می‌کند. شواهد release-ci/* نامعتبر است، زیرا انتشار هر اجرا را به شاخهٔ canonical و SHA انتشار مقید می‌کند. tag، تصاویر Gateway و فقط aliasهای extended-stable* را منتشر می‌کند؛ این مسیر از هماهنگ‌کنندهٔ معمول و سطوح ClawHub، برنامهٔ بومی، GitHub Release، وب‌سایت و dist-tag خصوصی آن عبور نمی‌کند. برای فرمان‌ها و بازیابی، به انتشار ماهانهٔ extended-stable مربوط به Gateway مراجعه کنید.

اجراکننده‌ها

بودجهٔ ثبت اجراکننده

bucket فعلی ثبت اجراکنندهٔ GitHub در OpenClaw، در ghx api rate_limit تعداد 10,000 ثبت اجراکنندهٔ self-hosted را در هر 5 دقیقه گزارش می‌کند. پیش از هر نوبت تنظیم، actions_runner_registration را دوباره بررسی کنید، زیرا GitHub می‌تواند این bucket را تغییر دهد. این محدودیت میان همهٔ ثبت‌های اجراکنندهٔ Blacksmith در سازمان openclaw مشترک است؛ بنابراین افزودن نصب دیگری از Blacksmith، bucket جدیدی اضافه نمی‌کند.

برچسب‌های Blacksmith را منبع کمیاب برای کنترل جهش در نظر بگیرید. jobهایی که فقط مسیریابی، اطلاع‌رسانی، تلخیص یا انتخاب shard انجام می‌دهند یا اسکن‌های کوتاه CodeQL را اجرا می‌کنند، باید روی اجراکننده‌های میزبانی‌شده توسط GitHub باقی بمانند، مگر اینکه نیازهای اندازه‌گیری‌شدهٔ مختص Blacksmith داشته باشند. هر ماتریس جدید Blacksmith، مقدار بزرگ‌تر max-parallel یا گردش‌کار پرتکرار باید شمار ثبت در بدترین حالت را نشان دهد و هدف سطح سازمان را پایین‌تر از حدود 60% bucket فعال نگه دارد. با bucket فعلی شامل 10,000 ثبت، این به‌معنای هدف عملیاتی 6,000 ثبت است که برای مخزن‌های هم‌زمان، تلاش‌های مجدد و هم‌پوشانی جهش‌ها ظرفیت آزاد باقی می‌گذارد.

طرح Pull request مبتنی بر هدف‌های تغییریافته، جهش معمول آزمون Node را از 14 ثبت Blacksmith به یک ثبت کاهش می‌دهد. Pull requestهای دارای ریسک گسترده، راهکار جایگزین فشردهٔ 14 ثبتی را حفظ می‌کنند؛ بنابراین بدترین حالت افزایش نمی‌یابد.

پایپ‌لاین CI مخزن canonical، Blacksmith را به‌عنوان مسیر پیش‌فرض اجراکننده برای اجراهای عادی push و Pull request حفظ می‌کند. workflow_dispatch و اجراهای مخزن غیر canonical از اجراکننده‌های میزبانی‌شده توسط GitHub استفاده می‌کنند، اما اجراهای عادی canonical در حال حاضر سلامت صف Blacksmith را بررسی نمی‌کنند و هنگام در دسترس نبودن Blacksmith، به‌طور خودکار به برچسب‌های میزبانی‌شده توسط GitHub بازنمی‌گردند.

جغجغه‌های سطح

دو بودجهٔ فقط‌کاهشی از سطح پیکربندی محافظت می‌کنند. هر دو در صورت رشد، پایپ‌لاین CI را ناموفق می‌کنند تا زمانی که فایل بودجه آگاهانه در همان Pull request به‌روزرسانی شود، و هر دو هنگامی که پاک‌سازی شمار واقعی را کاهش می‌دهد، کاهش جغجغه‌ای را الزامی می‌کنند.

• config/env-var-count-budget.txt تعداد نام‌های متمایز OPENCLAW_* در منبع production زیر src/، packages/ و extensions/ را محدود می‌کند (آزمون‌ها و QA Lab مستثنا هستند). با node scripts/check-env-var-count.mjs بررسی می‌شود. هنگام حذف متغیرهای محیطی، عدد را در همان Pull request کاهش دهید. افزودن یک مورد، تصمیمی دربارهٔ سطح پیکربندی است — آن را در بدنهٔ Pull request توجیه کنید.
• docs/.generated/config-baseline.counts.json شمار ورودی‌های schema متعلق به openclaw.json را به‌تفکیک نوع (core/channel/plugin) محدود می‌کند. با pnpm config:docs:check بررسی می‌شود؛ پس از هر تغییر schema، با pnpm config:docs:gen دوباره تولید کنید.

معادل‌های محلی

pnpm changed:lanes                            # بررسی دسته‌بند محلی خط‌های تغییریافته برای origin/main...HEADpnpm check:changed                            # دروازه بررسی محلی هوشمند: قالب‌بندی/بررسی نوع/lint/محافظ‌های تغییریافته بر اساس خط مرزیpnpm check                                    # دروازه محلی سریع: tsgo تولید + lint بخش‌بندی‌شده + محافظ‌های سریع موازیpnpm check:test-typespnpm check:timed                              # همان دروازه همراه با زمان‌بندی هر مرحلهpnpm build:strict-smokepnpm check:architecturepnpm test:gateway:watch-regressionOPENCLAW_TUI_PTY_INCLUDE_LOCAL=1 node scripts/run-vitest.mjs run --config test/vitest/vitest.tui-pty.config.tspnpm test                                     # آزمون‌های vitestpnpm test:changed                             # اهداف هوشمند و کم‌هزینه Vitest برای تغییراتpnpm test:ui                                  # مجموعه آزمون واحد/مرورگر رابط کاربری کنترلpnpm ui:i18n:check                            # برابری تولیدشده زبان‌های رابط کاربری کنترل (دروازه انتشار)pnpm native:i18n:baseline                     # به‌روزرسانی فهرست استخراج بومی تحت مالکیت منبعpnpm native:i18n:verify                       # فهرست منبع + ایمنی بومی‌سازی Android/Applepnpm native:i18n:check                        # برابری سخت‌گیرانه ترجمه‌شده/تولیدشده برای پلتفرم (دروازه انتشار)pnpm test:channelspnpm test:contracts:channelspnpm check:docs                               # قالب‌بندی مستندات + lint + پیوندهای خرابpnpm build                                    # ساخت dist هنگامی که بررسی‌های آرتیفکت/دود CI اهمیت دارندpnpm ios:build                                # تولید و ساخت پروژه برنامه iOSpnpm ci:timings                               # خلاصه‌سازی جدیدترین اجرای پایپ‌لاین CI ناشی از push به origin/mainpnpm ci:timings:recent                        # مقایسه اجراهای موفق اخیر پایپ‌لاین CI شاخه mainnode scripts/ci-run-timings.mjs <run-id>      # خلاصه‌سازی زمان سپری‌شده، زمان صف و کندترین کارهاnode scripts/ci-run-timings.mjs --latest-main # نادیده‌گرفتن نویز issue/comment و انتخاب پایپ‌لاین CI ناشی از push به origin/mainnode scripts/ci-run-timings.mjs --recent 10   # مقایسه اجراهای موفق اخیر پایپ‌لاین CI شاخه mainpnpm test:perf:groups --full-suite --allow-failures --output .artifacts/test-perf/baseline-before.jsonpnpm test:perf:groups:compare .artifacts/test-perf/baseline-before.json .artifacts/test-perf/after-agent.jsonpnpm test:startup:memorypnpm test:extensions:memory -- --json .artifacts/openclaw-performance/source/mock-provider/extension-memory.jsonpnpm perf:kova:summary --report .artifacts/kova/reports/mock-provider/report.json --output .artifacts/kova/summary.md

عملکرد OpenClaw

OpenClaw Performance گردش‌کار عملکرد محصول/زمان‌اجرا است. این گردش‌کار هر روز روی main اجرا می‌شود و می‌توان آن را به‌صورت دستی راه‌اندازی کرد:

gh workflow run openclaw-performance.yml --ref main -f profile=diagnostic -f repeat=3gh workflow run openclaw-performance.yml --ref main -f profile=smoke -f repeat=1 -f deep_profile=true -f live_openai_candidate=truegh workflow run openclaw-performance.yml --ref main -f target_ref=v2026.5.2 -f profile=diagnostic -f repeat=3

راه‌اندازی دستی معمولاً بنچمارک را روی ref گردش‌کار اجرا می‌کند. برای بنچمارک‌گیری از یک تگ انتشار یا شاخه‌ای دیگر با پیاده‌سازی فعلی گردش‌کار، target_ref را تنظیم کنید. مسیرهای گزارش منتشرشده و اشاره‌گرهای جدیدترین نسخه بر اساس ref آزمایش‌شده کلیدگذاری می‌شوند و هر index.md، ref/SHA آزمایش‌شده، ref/SHA گردش‌کار، ref مربوط به Kova، پروفایل، حالت احراز هویت خط، مدل، تعداد تکرار و فیلترهای سناریو را ثبت می‌کند.

این گردش‌کار OCM را از یک انتشار پین‌شده و Kova را از openclaw/Kova با ورودی پین‌شده kova_ref نصب می‌کند، سپس سه خط را اجرا می‌کند:

• mock-provider: سناریوهای تشخیصی Kova در برابر زمان‌اجرای ساخته‌شده محلی با احراز هویت جعلی، قطعی و سازگار با OpenAI.
• mock-deep-profile: پروفایل‌گیری CPU/heap/ردیابی برای نقاط داغ راه‌اندازی، Gateway و نوبت عامل. طبق زمان‌بندی یا هنگام راه‌اندازی با deep_profile=true اجرا می‌شود.
• live-openai-candidate: یک نوبت واقعی عامل OpenAI openai/gpt-5.6-luna که در صورت دردسترس‌نبودن OPENAI_API_KEY رد می‌شود. طبق زمان‌بندی یا هنگام راه‌اندازی با live_openai_candidate=true اجرا می‌شود.

خط ارائه‌دهنده ساختگی همچنین پس از عبور Kova، کاوشگرهای منبع بومی OpenClaw را اجرا می‌کند: زمان و حافظه راه‌اندازی Gateway در حالت‌های پیش‌فرض، کانال ردشده، هوک داخلی و راه‌اندازی با پنجاه Plugin؛ RSS واردکردن Pluginهای همراه، حلقه‌های تکراری سلام channel-chat-baseline با OpenAI ساختگی، فرمان‌های راه‌اندازی CLI در برابر Gateway راه‌اندازی‌شده و کاوشگر دود عملکرد وضعیت SQLite. هنگامی که گزارش منبع قبلی منتشرشده ارائه‌دهنده ساختگی برای ref آزمایش‌شده در دسترس باشد، خلاصه منبع مقادیر فعلی RSS و heap را با آن خط مبنا مقایسه می‌کند و افزایش‌های بزرگ RSS را به‌عنوان watch علامت می‌زند. خلاصه Markdown کاوشگر منبع در source/index.md در بسته گزارش قرار دارد و JSON خام نیز کنار آن است.

هر خط آرتیفکت کامل GitHub خود، شامل بسته‌های CPU، heap، ردیابی و بسته‌های تشخیصی فشرده را بارگذاری می‌کند. یک کار انتشاردهنده جداگانه این آرتیفکت‌ها را دانلود و اعتبارسنجی می‌کند، سپس یک توکن کوتاه‌عمر GitHub App متعلق به ClawSweeper ایجاد می‌کند که فقط به محتوای openclaw/clawgrit-reports محدود است و آن را فقط به مرحله Git push می‌دهد. این کار report.json، report.md، index.md، آرتیفکت‌های کاوشگر منبع و فراداده/جمع‌های مقابله‌ای بسته را زیر openclaw-performance/<tested-ref>/<run-id>-<attempt>/<lane>/ ثبت می‌کند؛ بایگانی تشخیصی کامل در آرتیفکت پیوندشده Actions باقی می‌ماند. انتشاردهنده پیش از تلاش برای push، هر فایل گزارش بزرگ‌تر از 50 MB را رد می‌کند. اشاره‌گر فعلی ref آزمایش‌شده openclaw-performance/<tested-ref>/latest-<lane>.json است. اجراهای زمان‌بندی‌شده و راه‌اندازی‌های profile=release در صورت شکست ایجاد توکن برنامه یا انتشار گزارش، شکست می‌خورند. راه‌اندازی‌های دستی غیرانتشاری، انتشار را مشورتی نگه می‌دارند و در صورت شکست احراز هویت یا انتشار، آرتیفکت‌های GitHub را حفظ می‌کنند. خط مبنای منبع قبلی به‌صورت ناشناس از مخزن عمومی گزارش‌ها دریافت می‌شود؛ بنابراین دریافت موفق خط مبنا، احراز هویت انتشاردهنده را اثبات نمی‌کند.

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

Full Release Validation گردش‌کار چتری دستی برای «اجرای همه‌چیز پیش از انتشار» است. این گردش‌کار یک شاخه، تگ یا SHA کامل commit می‌پذیرد، گردش‌کار دستی CI را با آن هدف (از جمله Android) راه‌اندازی می‌کند، Plugin Prerelease را برای اثبات مختص انتشارِ Plugin/بسته/ایستا/Docker راه‌اندازی می‌کند، OpenClaw Performance را در برابر SHA هدف راه‌اندازی می‌کند و OpenClaw Release Checks را برای آزمون دود نصب، پذیرش بسته، بررسی‌های میان‌سیستم‌عاملی بسته، برابری QA Lab، Matrix، Telegram و خط‌های مشروط Discord، WhatsApp و Slack راه‌اندازی می‌کند (رندر مشورتی کارت امتیاز بلوغ از طریق run_maturity_scorecard اختیاری است). پروفایل‌های پایدار و کامل همیشه پوشش جامع live/E2E و آزمون ماندگاری مسیر انتشار Docker را شامل می‌شوند؛ پروفایل بتا می‌تواند با run_release_soak=true آن را فعال کند. E2E استاندارد Telegram بسته درون پذیرش بسته اجرا می‌شود، بنابراین یک نامزد کامل یک poller زنده تکراری را آغاز نمی‌کند. پس از انتشار، release_package_spec را بدهید تا بسته npm منتشرشده در بررسی‌های انتشار، پذیرش بسته، Docker، میان‌سیستم‌عاملی و Telegram بدون ساخت مجدد استفاده شود. npm_telegram_package_spec را فقط برای اجرای مجدد متمرکز Telegram روی بسته منتشرشده استفاده کنید. خط بسته زنده Plugin مربوط به Codex به‌طور پیش‌فرض از همان وضعیت انتخاب‌شده استفاده می‌کند: release_package_spec=openclaw@<tag> منتشرشده، codex_plugin_spec=npm:@openclaw/codex@<tag> را مشتق می‌کند، درحالی‌که اجراهای SHA/آرتیفکت، extensions/codex را از ref انتخاب‌شده بسته‌بندی می‌کنند. برای منابع سفارشی Plugin مانند مشخصات npm:، npm-pack: یا git:، مقدار codex_plugin_spec را صریحاً تنظیم کنید. اثبات عامل زنده آن، پیشرفت قابل‌مشاهده ارسال می‌کند، خواندن‌های تصادفی فضای کاری و نوشتن دقیق آرتیفکت را ادامه می‌دهد و سپس پیام تکمیل را می‌فرستد.

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

OpenClaw Release Publish گردش‌کار دستی تغییردهنده انتشار است. انتشارهای عادی بتا و پایدار را پس از وجود تگ انتشار و موفقیت پیش‌بررسی npm مربوط به OpenClaw از main قابل‌اعتماد راه‌اندازی کنید (پیش‌بررسی در میان بررسی‌های خود pnpm plugins:sync:check را اجرا می‌کند). تگ همچنان commit دقیق انتشار، از جمله commit روی release/YYYY.M.PATCH را انتخاب می‌کند؛ انتشارهای آلفای Tideclaw همچنان از شاخه آلفای متناظر خود استفاده می‌کنند. این گردش‌کار به preflight_run_id ذخیره‌شده و یک full_release_validation_run_id موفق و full_release_validation_run_attempt دقیق آن نیاز دارد، Plugin NPM Release را برای همه بسته‌های قابل‌انتشار Plugin راه‌اندازی می‌کند، Plugin ClawHub Release را برای همان SHA انتشار راه‌اندازی می‌کند و فقط پس از آن OpenClaw NPM Release را راه‌اندازی می‌کند. انتشار پایدار همچنین به یک windows_node_tag دقیق نیاز دارد؛ گردش‌کار پیش از هر فرزند انتشار، انتشار منبع Windows را تأیید می‌کند و نصب‌کننده‌های x64/ARM64 آن را با ورودی windows_node_installer_digests تأییدشده توسط نامزد مقایسه می‌کند، سپس همان digestهای پین‌شده نصب‌کننده به‌همراه قرارداد دقیق آرتیفکت همراه و جمع مقابله‌ای را پیش از انتشار پیش‌نویس انتشار GitHub ترویج و تأیید می‌کند. تعمیرهای متمرکز فقط برای Plugin از plugin_publish_scope=selected با یک فهرست بسته غیرخالی استفاده می‌کنند. اجراهای فقط Plugin مربوط به all-publishable به همان پیش‌بررسی تغییرناپذیر npm و شواهد اعتبارسنجی کامل انتشارِ یک انتشار هسته نیاز دارند.

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

برای اثبات commit پین‌شده روی شاخه‌ای با تغییرات سریع، به‌جای gh workflow run ... --ref main -f ref=<sha> از ابزار کمکی استفاده کنید:

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

refهای راه‌اندازی گردش‌کار GitHub باید شاخه یا تگ باشند، نه SHA خام commit. ابزار کمکی یک شاخه موقت release-ci/<sha>-... را روی SHA گردش‌کار main قابل‌اعتماد push می‌کند، SHA هدف درخواست‌شده را از طریق ورودی ref گردش‌کار می‌فرستد، در صورت وجود از شواهد سخت‌گیرانه هدف دقیق دوباره استفاده می‌کند، تأیید می‌کند که headSha هر گردش‌کار فرزند با SHA گردش‌کار قابل‌اعتماد مطابقت دارد و پس از تکمیل اجرا، شاخه موقت را حذف می‌کند. برای اجبار اعتبارسنجی تازه، -f reuse_evidence=false را بدهید. اعتبارسنج چتری همچنین اگر هر گردش‌کار فرزند با SHA گردش‌کار متفاوتی اجرا شده باشد، شکست می‌خورد.

release_profile گستره live/ارائه‌دهنده منتقل‌شده به بررسی‌های انتشار را کنترل می‌کند. گردش‌کارهای دستی انتشار به‌طور پیش‌فرض از stable استفاده می‌کنند؛ فقط زمانی از full استفاده کنید که عمداً ماتریس گسترده و مشورتی ارائه‌دهنده/رسانه را می‌خواهید. بررسی‌های انتشار پایدار و کامل همیشه آزمون ماندگاری جامع live/E2E و مسیر انتشار Docker را اجرا می‌کنند؛ پروفایل بتا می‌تواند با run_release_soak=true آن را فعال کند.

• beta سریع‌ترین خط‌های حیاتی انتشار OpenAI/هسته را نگه می‌دارد.
• stable مجموعه پایدار ارائه‌دهنده/بک‌اند را اضافه می‌کند.
• full ماتریس گسترده و مشورتی ارائه‌دهنده/رسانه را اجرا می‌کند.

گردش‌کار چتری شناسه‌های اجرای فرزند راه‌اندازی‌شده را ثبت می‌کند و کار نهایی Verify full validation نتیجه‌گیری‌های فعلی اجرای فرزندان را دوباره بررسی می‌کند و جدول‌های کندترین کارها را برای هر اجرای فرزند می‌افزاید. اگر یک گردش‌کار فرزند دوباره اجرا شود و سبز شود، فقط کار اعتبارسنج والد را دوباره اجرا کنید تا نتیجه گردش‌کار چتری و خلاصه زمان‌بندی به‌روزرسانی شود.

برای بازیابی، هر دو Full Release Validation و OpenClaw Release Checks مقدار rerun_group را می‌پذیرند. برای یک نامزد انتشار از all، فقط برای فرزند عادی CI کامل از ci، فقط برای فرزند پیش‌انتشار Plugin از plugin-prerelease، فقط برای فرزند عملکرد OpenClaw از performance، برای همه فرزندان انتشار از release-checks، یا در چتر اصلی از یک گروه محدودتر استفاده کنید: install-smoke، cross-os، live-e2e، package، qa، qa-parity، qa-live، یا npm-telegram. این کار اجرای مجدد یک جعبه انتشار ناموفق را پس از یک اصلاح متمرکز، محدود نگه می‌دارد. برای یک مسیر ناموفق میان‌سیستم‌عاملی، rerun_group=cross-os را با cross_os_suite_filter ترکیب کنید، برای مثال windows/packaged-upgrade؛ فرمان‌های طولانی میان‌سیستم‌عاملی خطوط Heartbeat منتشر می‌کنند و خلاصه‌های ارتقای بسته‌بندی‌شده شامل زمان‌بندی هر مرحله‌اند. مسیرهای منتخب QA در Matrix و Telegram اعتبارسنجی عادی انتشار را مسدود می‌کنند و دروازه پوشش ابزارِ جفت زمان‌اجرای هسته نیز چنین است. هم‌ترازی QA، هم‌ترازی زمان اجرا و مسیرهای زنده دروازه‌دار Discord، WhatsApp و Slack جنبه توصیه‌ای دارند.

OpenClaw Release Checks با استفاده از ارجاع گردش‌کار مورد اعتماد، ارجاع انتخاب‌شده را یک‌بار به یک آرشیو release-package-under-test تبدیل می‌کند، سپس آن مصنوع را به بررسی‌های میان‌سیستم‌عاملی و پذیرش بسته، و نیز هنگام اجرای پوشش آزمون ماندگاری به گردش‌کار Docker مسیر انتشار زنده/E2E می‌فرستد. این کار بایت‌های بسته را میان جعبه‌های انتشار یکسان نگه می‌دارد و از بسته‌بندی دوباره همان نامزد در چندین کار فرزند جلوگیری می‌کند. برای مسیر زنده npm-plugin مربوط به Codex، بررسی‌های انتشار یا یک مشخصات Plugin منتشرشده و منطبق را که از release_package_spec مشتق شده است ارسال می‌کنند، یا codex_plugin_spec ارائه‌شده توسط اپراتور را می‌فرستند، یا ورودی را خالی می‌گذارند تا اسکریپت Docker، Plugin مربوط به Codex در checkout انتخاب‌شده را بسته‌بندی کند.

اجراهای تکراری Full Release Validation برای ref=main و rerun_group=all جایگزین چتر قدیمی‌تر می‌شوند. هنگامی که والد لغو شود، پایشگر والد هر گردش‌کار فرزندی را که پیش‌تر اعزام کرده است لغو می‌کند؛ بنابراین اعتبارسنجی جدیدتر main پشت یک اجرای منقضی‌شده دوساعته بررسی انتشار منتظر نمی‌ماند. اعتبارسنجی شاخه/برچسب انتشار و گروه‌های اجرای مجدد متمرکز، cancel-in-progress: false را حفظ می‌کنند.

شاردهای زنده و E2E

فرزند زنده/E2E انتشار، پوشش گسترده بومی pnpm test:live را حفظ می‌کند، اما آن را به‌جای یک کار ترتیبی، از طریق scripts/test-live-shard.mjs به‌صورت شاردهای نام‌گذاری‌شده اجرا می‌کند:

• native-live-src-agents و native-live-src-agents-zai-coding
• native-live-src-gateway-core
• کارهای native-live-src-gateway-profiles فیلترشده بر اساس ارائه‌دهنده
• native-live-src-gateway-backends
• native-live-src-infra
• native-live-test
• native-live-extensions-a-k
• native-live-extensions-l-n
• native-live-extensions-moonshot
• native-live-extensions-openai
• native-live-extensions-o-z-other
• native-live-extensions-xai
• شاردهای جداشده صوتی/ویدیویی رسانه و شاردهای موسیقی فیلترشده بر اساس ارائه‌دهنده

این کار همان پوشش فایل را حفظ می‌کند و در عین حال اجرای مجدد و عیب‌یابی شکست‌های کند ارائه‌دهنده زنده را آسان‌تر می‌سازد. نام‌های شارد تجمیعی native-live-src-gateway، native-live-extensions-o-z، native-live-extensions-media و native-live-extensions-media-music همچنان برای اجراهای مجدد دستی یک‌مرحله‌ای معتبرند.

شاردهای بومی رسانه زنده در ghcr.io/openclaw/openclaw-live-media-runner:ubuntu-24.04 اجرا می‌شوند که گردش‌کار Live Media Runner Image آن را می‌سازد. آن تصویر، ffmpeg و ffprobe را از پیش نصب می‌کند؛ کارهای رسانه فقط پیش از راه‌اندازی، فایل‌های اجرایی را تأیید می‌کنند. مجموعه‌های زنده مبتنی بر Docker را روی اجراکننده‌های عادی Blacksmith نگه دارید — کارهای کانتینری محل مناسبی برای راه‌اندازی آزمون‌های Docker تودرتو نیستند.

شاردهای مدل/بک‌اند زنده مبتنی بر Docker برای هر commit انتخاب‌شده از یک تصویر مشترک جداگانه ghcr.io/openclaw/openclaw-live-test:<sha>-<extensions> استفاده می‌کنند. گردش‌کار انتشار زنده آن تصویر را یک‌بار می‌سازد و push می‌کند، سپس شاردهای مدل زنده Docker، Gateway شاردشده بر اساس ارائه‌دهنده، بک‌اند CLI، اتصال ACP و هارنس Codex با OPENCLAW_SKIP_DOCKER_BUILD=1 اجرا می‌شوند. شاردهای Docker مربوط به Gateway محدودیت‌های صریح timeout در سطح اسکریپت دارند که پایین‌تر از مهلت کار گردش‌کار است؛ بنابراین یک کانتینر گیرکرده یا مسیر پاک‌سازی، به‌جای مصرف کل بودجه بررسی انتشار، سریع شکست می‌خورد. اگر آن شاردها هدف کامل Docker منبع را به‌طور مستقل دوباره بسازند، اجرای انتشار پیکربندی نادرستی دارد و زمان واقعی را صرف ساخت‌های تکراری تصویر خواهد کرد.

پذیرش بسته

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

کارها

1. resolve_package، workflow_ref را checkout می‌کند، یک نامزد بسته را حل می‌کند، .artifacts/docker-e2e-package/openclaw-current.tgz را می‌نویسد، .artifacts/docker-e2e-package/package-candidate.json را می‌نویسد، هر دو را به‌عنوان مصنوع package-under-test بارگذاری می‌کند و منبع، ارجاع گردش‌کار، ارجاع بسته، نسخه، SHA-256 و پروفایل را در خلاصه مرحله GitHub چاپ می‌کند.
2. package_integrity، مصنوع package-under-test را دانلود می‌کند و قرارداد عمومی tarball بسته را با scripts/check-openclaw-package-tarball.mjs اعمال می‌کند.
3. docker_acceptance، با SHA منبع بسته حل‌شده ــ و در صورت نبود آن با workflow_ref ــ و package_artifact_name=package-under-test، تابع openclaw-live-and-e2e-checks-reusable.yml را فراخوانی می‌کند. گردش‌کار قابل‌استفاده مجدد آن مصنوع را دانلود می‌کند، موجودی tarball را اعتبارسنجی می‌کند، در صورت نیاز تصاویر Docker مبتنی بر digest بسته را آماده می‌کند و مسیرهای Docker انتخاب‌شده را به‌جای بسته‌بندی checkout گردش‌کار، در برابر آن بسته اجرا می‌کند. وقتی یک پروفایل چند docker_lanes هدفمند را انتخاب کند، گردش‌کار قابل‌استفاده مجدد بسته و تصاویر مشترک را یک‌بار آماده می‌کند، سپس آن مسیرها را به‌صورت کارهای هدفمند موازی Docker با مصنوعات یکتا منشعب می‌کند.
4. package_telegram در صورت انتخاب، NPM Telegram Beta E2E را فراخوانی می‌کند. این کار وقتی اجرا می‌شود که telegram_mode برابر با none نباشد و اگر پذیرش بسته یک مورد را حل کرده باشد، همان مصنوع package-under-test را نصب می‌کند؛ اعزام مستقل Telegram همچنان می‌تواند یک مشخصات npm منتشرشده را نصب کند.
5. summary اگر حل بسته، یکپارچگی، پذیرش Docker یا مسیر اختیاری Telegram شکست بخورد، گردش‌کار را ناموفق می‌کند. ورودی advisory برای فراخوانندگان توصیه‌ای، شکست‌های پذیرش را به هشدار تنزل می‌دهد.

منابع نامزد

• source=npm فقط openclaw@extended-stable، openclaw@beta، openclaw@latest یا یک نسخه دقیق انتشار OpenClaw مانند openclaw@2026.4.27-beta.2 را می‌پذیرد. از این مورد برای پذیرش extended-stable، پیش‌انتشار یا انتشار پایدار منتشرشده استفاده کنید.
• source=ref یک شاخه، برچسب یا SHA کامل commit مورد اعتماد package_ref را بسته‌بندی می‌کند. حل‌کننده شاخه‌ها/برچسب‌های OpenClaw را واکشی می‌کند، تأیید می‌کند که commit انتخاب‌شده از تاریخچه شاخه مخزن یا یک برچسب انتشار قابل‌دسترسی است، وابستگی‌ها را در یک worktree جداشده نصب می‌کند و آن را با scripts/package-openclaw-for-docker.mjs بسته‌بندی می‌کند.
• source=url یک .tgz عمومی HTTPS را دانلود می‌کند؛ package_sha256 الزامی است. این مسیر اعتبارنامه‌های URL، پورت‌های غیرپیش‌فرض HTTPS، نام‌های میزبان یا IPهای حل‌شده خصوصی/داخلی/دارای کاربرد ویژه و تغییرمسیرهای خارج از همان سیاست ایمنی عمومی را رد می‌کند.
• source=trusted-url یک .tgz مبتنی بر HTTPS را از یک سیاست منبع مورد اعتماد نام‌گذاری‌شده در .github/package-trusted-sources.json دانلود می‌کند؛ package_sha256 و trusted_source_id الزامی‌اند. از این مورد فقط برای آینه‌های سازمانی متعلق به نگه‌دارنده یا مخازن بسته خصوصی استفاده کنید که به میزبان‌ها، پورت‌ها، پیشوندهای مسیر، میزبان‌های تغییرمسیر یا تفکیک شبکه خصوصی پیکربندی‌شده نیاز دارند. اگر سیاست، احراز هویت bearer را اعلام کند، گردش‌کار از secret ثابت OPENCLAW_TRUSTED_PACKAGE_TOKEN استفاده می‌کند؛ اعتبارنامه‌های تعبیه‌شده در URL همچنان رد می‌شوند.
• source=artifact یک .tgz را از artifact_run_id و artifact_name دانلود می‌کند؛ package_sha256 اختیاری است، اما باید برای مصنوعات اشتراک‌گذاری‌شده بیرونی ارائه شود.

workflow_ref و package_ref را جدا نگه دارید. workflow_ref کد مورد اعتماد گردش‌کار/هارنس است که آزمون را اجرا می‌کند. package_ref، commit منبعی است که هنگام source=ref بسته‌بندی می‌شود. این امکان می‌دهد هارنس آزمون فعلی بدون اجرای منطق قدیمی گردش‌کار، commitهای قدیمی‌تر منبع مورد اعتماد را اعتبارسنجی کند.

پروفایل‌های مجموعه

• smoke — npm-onboard-channel-agent، gateway-network، config-reload
• package — npm-onboard-channel-agent، 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
• product — مجموعه package با پوشش زنده plugins به‌جای plugins-offline، به‌علاوه mcp-channels، cron-mcp-cleanup، openai-web-search-minimal، openwebui
• full — بخش‌های کامل مسیر انتشار Docker با OpenWebUI
• custom — دقیقاً docker_lanes؛ هنگام suite_profile=custom الزامی است

پروفایل package از پوشش آفلاین Plugin استفاده می‌کند تا اعتبارسنجی بسته منتشرشده به دسترس‌بودن زنده ClawHub وابسته نباشد. مسیر اختیاری Telegram از مصنوع package-under-test در NPM Telegram Beta E2E دوباره استفاده می‌کند و مسیر مشخصات npm منتشرشده برای اعزام‌های مستقل حفظ می‌شود.

برای سیاست اختصاصی آزمون به‌روزرسانی و Plugin، از جمله فرمان‌های محلی، مسیرهای Docker، ورودی‌های پذیرش بسته، پیش‌فرض‌های انتشار و عیب‌یابی شکست، به آزمون به‌روزرسانی‌ها و Pluginها مراجعه کنید.

بررسی‌های انتشار، پذیرش بسته را با 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 فراخوانی می‌کنند. این کار مهاجرت بسته، به‌روزرسانی، نصب زنده Skills از ClawHub، پاک‌سازی وابستگی منقضی‌شده Plugin، ترمیم نصب Plugin پیکربندی‌شده، Plugin آفلاین، به‌روزرسانی Plugin و اثبات Telegram را روی همان tarball بسته حل‌شده نگه می‌دارد. پس از انتشار یک نسخه بتا، release_package_spec را روی اعتبارسنجی کامل انتشار یا بررسی‌های انتشار OpenClaw تنظیم کنید تا همان ماتریس بدون ساخت مجدد در برابر بسته npm عرضه‌شده اجرا شود؛ package_acceptance_package_spec را فقط زمانی تنظیم کنید که پذیرش بسته به بسته‌ای متفاوت از بقیه اعتبارسنجی انتشار نیاز دارد. بررسی‌های انتشار میان‌سیستم‌عاملی همچنان onboarding، نصب‌کننده و رفتار پلتفرم ویژه هر سیستم‌عامل را پوشش می‌دهند؛ اعتبارسنجی محصولِ بسته/به‌روزرسانی باید با پذیرش بسته آغاز شود.

مسیر Docker مربوط به published-upgrade-survivor در هر اجرا، یک خط مبنای بسته منتشرشده را در مسیر مسدودکننده انتشار اعتبارسنجی می‌کند. در پذیرش بسته، tarball حل‌شده package-under-test همیشه نامزد است و published_upgrade_survivor_baseline خط مبنای منتشرشده جایگزین را انتخاب می‌کند که مقدار پیش‌فرض آن openclaw@latest است؛ فرمان‌های اجرای مجدد مسیر ناموفق آن خط مبنا را حفظ می‌کنند. اعتبارسنجی کامل انتشار با run_release_soak=true یا release_profile=full، مقادیر published_upgrade_survivor_baselines='last-stable-4 2026.4.23 2026.5.2 2026.4.15' و published_upgrade_survivor_scenarios=reported-issues را تنظیم می‌کند تا پوشش به چهار انتشار پایدار اخیر npm، به‌علاوه انتشارهای مرزی سنجاق‌شده سازگاری Plugin و نمونه‌های برگرفته از issue برای پیکربندی Feishu، فایل‌های حفظ‌شده bootstrap/persona، نصب Pluginهای پیکربندی‌شده OpenClaw، مسیرهای log دارای tilde و ریشه‌های منقضی‌شده وابستگی Plugin قدیمی گسترش یابد. انتخاب‌های بازمانده ارتقای منتشرشده با چند خط مبنا، بر اساس خط مبنا به کارهای جداگانه اجراکننده هدفمند Docker شارد می‌شوند. گردش‌کار جداگانه Update Migration هنگامی از مسیر Docker مربوط به update-migration با خطوط مبنای all-since-2026.4.23 و سناریوهای plugin-deps-cleanup استفاده می‌کند که پرسش درباره پاک‌سازی جامع به‌روزرسانی منتشرشده باشد، نه گستره عادی CI کامل انتشار. اجراهای تجمیعی محلی می‌توانند مشخصات دقیق بسته را با OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPECS ارسال کنند، با OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC مانند openclaw@2026.4.15 یک مسیر واحد را نگه دارند، یا OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS را برای ماتریس سناریو تنظیم کنند. مسیر منتشرشده، خط مبنا را با دستورالعمل فرمان تعبیه‌شده openclaw config set پیکربندی می‌کند، مراحل دستورالعمل را در summary.json ثبت می‌کند و پس از شروع Gateway، /healthz، /readyz و وضعیت RPC را می‌سنجد. مسیرهای تازه بسته‌بندی‌شده و نصب‌کننده Windows همچنین تأیید می‌کنند که یک بسته نصب‌شده می‌تواند یک override کنترل مرورگر را از یک مسیر خام و مطلق Windows وارد کند. آزمون دودِ گردش عامل OpenAI میان‌سیستم‌عاملی در صورت تنظیم، به‌طور پیش‌فرض از OPENCLAW_CROSS_OS_OPENAI_MODEL و در غیر این صورت از openai/gpt-5.6-luna استفاده می‌کند تا اثبات نصب و Gateway از رده آزمون کم‌هزینه‌تر GPT-5.6 استفاده کند.

بازه‌های سازگاری قدیمی

Package Acceptance برای بسته‌های ازپیش‌منتشرشده، بازه‌های محدود سازگاری با نسخه‌های قدیمی دارد. بسته‌ها تا 2026.4.25، از جمله 2026.4.25-beta.*، می‌توانند از مسیر سازگاری استفاده کنند:

• ورودی‌های شناخته‌شدهٔ QA خصوصی در dist/postinstall-inventory.json می‌توانند به فایل‌های حذف‌شده از tarball اشاره کنند؛
• doctor-switch می‌تواند زیرحالت ماندگاری gateway install --wrapper را هنگامی که بسته آن پرچم را ارائه نمی‌کند، رد کند؛
• update-channel-switch می‌تواند pnpm patchedDependencies مفقود را از fixture جعلی git مشتق‌شده از tarball حذف کند و می‌تواند update.channel ماندگارشدهٔ مفقود را ثبت کند؛
• آزمون‌های دود Plugin می‌توانند مکان‌های قدیمی رکورد نصب را بخوانند یا نبود ماندگاری رکورد نصب marketplace را بپذیرند؛
• plugin-update می‌تواند مهاجرت فرادادهٔ پیکربندی را مجاز کند، درحالی‌که همچنان الزام می‌کند رکورد نصب و رفتار بدون نصب مجدد بدون تغییر باقی بمانند.

بستهٔ منتشرشدهٔ 2026.4.26 همچنین می‌تواند برای فایل‌های مهر فرادادهٔ ساخت محلی که قبلاً منتشر شده‌اند هشدار دهد، و بسته‌ها تا 2026.5.20 می‌توانند هنگام نبود npm-shrinkwrap.json به‌جای شکست هشدار دهند. بسته‌های بعدی باید قراردادهای مدرن را برآورده کنند؛ همان شرایط به‌جای هشدار یا ردشدن، شکست می‌خورند.

نمونه‌ها

# بستهٔ بتای فعلی را با پوشش سطح محصول اعتبارسنجی کنید.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 telegram_mode=mock-openai # بستهٔ extended-stable منتشرشده را با پوشش بسته اعتبارسنجی کنید.gh workflow run package-acceptance.yml \  --ref main \  -f workflow_ref=main \  -f source=npm \  -f package_spec=openclaw@extended-stable \  -f suite_profile=package \  -f telegram_mode=mock-openai # یک شاخهٔ انتشار را با harness فعلی بسته‌بندی و اعتبارسنجی کنید.gh workflow run package-acceptance.yml \  --ref main \  -f workflow_ref=main \  -f source=ref \  -f package_ref=release/YYYY.M.PATCH \  -f suite_profile=package \  -f telegram_mode=mock-openai # یک URL مربوط به tarball را اعتبارسنجی کنید. برای source=url، مقدار SHA-256 الزامی است.gh workflow run package-acceptance.yml \  --ref main \  -f workflow_ref=main \  -f source=url \  -f package_url=https://example.com/openclaw-current.tgz \  -f package_sha256=<64-char-sha256> \  -f suite_profile=smoke # یک tarball را از سیاست آینهٔ خصوصی مورداعتماد و نام‌گذاری‌شده اعتبارسنجی کنید.gh workflow run package-acceptance.yml \  --ref main \  -f workflow_ref=main \  -f source=trusted-url \  -f trusted_source_id=enterprise-artifactory \  -f package_url=https://packages.example.internal:8443/artifactory/openclaw/openclaw-current.tgz \  -f package_sha256=<64-char-sha256> \  -f suite_profile=smoke # از tarball بارگذاری‌شده توسط اجرای دیگری از Actions دوباره استفاده کنید.gh workflow run package-acceptance.yml \  --ref main \  -f workflow_ref=main \  -f source=artifact \  -f artifact_run_id=<run-id> \  -f artifact_name=package-under-test \  -f suite_profile=custom \  -f docker_lanes='install-e2e plugin-update'

هنگام اشکال‌زدایی اجرای ناموفق پذیرش بسته، از خلاصهٔ resolve_package شروع کنید تا منبع، نسخه و SHA-256 بسته را تأیید کنید. سپس اجرای فرزند docker_acceptance و artifactهای Docker آن را بررسی کنید: .artifacts/docker-tests/**/summary.json، failures.json، گزارش‌های lane، زمان‌بندی فازها و فرمان‌های اجرای مجدد. به‌جای اجرای مجدد اعتبارسنجی کامل انتشار، اجرای مجدد پروفایل ناموفق بسته یا laneهای دقیق Docker را ترجیح دهید.

آزمون دود نصب

گردش‌کار Install Smoke دیگر روی Pull requestها یا pushهای main اجرا نمی‌شود. wrapper شبانه/دستی آن و اعتبارسنجی انتشار، هر دو هستهٔ فقط‌خواندنی install-smoke-reusable.yml را فراخوانی می‌کنند و هر اجرا مسیر کامل آزمون دود نصب را روی runnerهای میزبانی‌شده توسط GitHub طی می‌کند:

• تصویر آزمون دود Dockerfile ریشه برای هر SHA هدف یک‌بار ساخته می‌شود، در یک artifact تغییرناپذیر به بازبینی گردش‌کار و تلاش تولیدکننده متصل می‌شود، سپس توسط آزمون دود CLI، آزمون دود CLI حذف فضای کاری مشترک عامل‌ها، E2E شبکهٔ Gateway کانتینر و آزمون دود آرگومان ساخت Plugin همراه matrix بارگذاری می‌شود. آزمون دود Plugin، بازتاب نصب وابستگی زمان اجرا و بارگذاری Plugin بدون عیب‌یابی‌های خروج از نقطهٔ ورود را تأیید می‌کند.
• نصب بستهٔ QR و آزمون‌های دود Docker مربوط به نصب‌کننده/به‌روزرسانی (شامل laneهای نصب‌کنندهٔ Rocky Linux و یک lane به‌روزرسانی در برابر خط مبنای قابل‌پیکربندی npm در update_baseline_version) به‌صورت jobهای جداگانه اجرا می‌شوند تا کار نصب‌کننده پشت آزمون‌های دود تصویر ریشه منتظر نماند.

آزمون دود کند ارائه‌دهندهٔ تصویرِ نصب سراسری Bun به‌طور جداگانه با run_bun_global_install_smoke کنترل می‌شود. این آزمون طبق زمان‌بندی شبانه اجرا می‌شود، برای فراخوانی‌های گردش‌کار از بررسی‌های انتشار به‌طور پیش‌فرض فعال است و dispatchهای دستی Install Smoke می‌توانند آن را فعال کنند. CI عادی PR همچنان lane سریع رگرسیون راه‌انداز Bun را برای تغییرات مرتبط با Node اجرا می‌کند. آزمون‌های Docker مربوط به QR و نصب‌کننده، Dockerfileهای متمرکز بر نصب خود را حفظ می‌کنند.

E2E محلی Docker

pnpm test:docker:all یک تصویر مشترک آزمون زنده را از پیش می‌سازد، OpenClaw را یک‌بار به‌صورت tarball مربوط به npm بسته‌بندی می‌کند و دو تصویر مشترک scripts/e2e/Dockerfile می‌سازد:

• یک runner سادهٔ Node/Git برای laneهای نصب‌کننده/به‌روزرسانی/وابستگی Plugin؛
• یک تصویر عملیاتی که همان tarball را برای laneهای عملکرد عادی در /app نصب می‌کند.

تعریف‌های laneهای Docker در scripts/lib/docker-e2e-scenarios.mjs، منطق برنامه‌ریز در scripts/lib/docker-e2e-plan.mjs قرار دارند و runner فقط برنامهٔ انتخاب‌شده را اجرا می‌کند. زمان‌بند با OPENCLAW_DOCKER_E2E_BARE_IMAGE و OPENCLAW_DOCKER_E2E_FUNCTIONAL_IMAGE تصویر هر lane را انتخاب می‌کند، سپس laneها را با OPENCLAW_SKIP_DOCKER_BUILD=1 اجرا می‌کند.

پارامترهای قابل‌تنظیم

یک lane سنگین‌تر از سقف مؤثر خود همچنان می‌تواند از یک pool خالی شروع شود، سپس تا زمانی که ظرفیت را آزاد کند به‌تنهایی اجرا می‌شود. تجمیع‌کنندهٔ محلی، Docker را پیش‌بررسی می‌کند، کانتینرهای قدیمی E2E مربوط به OpenClaw را حذف می‌کند، وضعیت laneهای فعال را منتشر می‌کند، زمان‌بندی laneها را برای ترتیب‌دهی از طولانی‌ترین به کوتاه‌ترین ماندگار می‌کند و به‌طور پیش‌فرض پس از نخستین شکست، زمان‌بندی laneهای تجمیع‌شدهٔ جدید را متوقف می‌کند.

گردش‌کار زنده/E2E قابل‌استفادهٔ مجدد

گردش‌کار زنده/E2E قابل‌استفادهٔ مجدد از scripts/test-docker-all.mjs --plan-json می‌پرسد کدام بسته، نوع تصویر، تصویر زنده، lane و پوشش اعتبارنامه لازم است. سپس scripts/docker-e2e.mjs آن برنامه را به خروجی‌ها و خلاصه‌های GitHub تبدیل می‌کند. این گردش‌کار یا OpenClaw را از طریق scripts/package-openclaw-for-docker.mjs بسته‌بندی می‌کند، یا artifact بستهٔ اجرای فعلی را بارگیری می‌کند، یا artifact بسته‌ای را از package_artifact_run_id بارگیری می‌کند و سپس موجودی tarball را اعتبارسنجی می‌کند. مسیر پیش‌فرض no-push-artifact تصاویر ساده/عملیاتی برچسب‌خورده با digest بسته را از طریق کش لایهٔ Docker متعلق به Blacksmith می‌سازد، بایت‌های دقیق تصویر را در یک artifact تغییرناپذیر گردش‌کار بسته‌بندی می‌کند و هر مصرف‌کننده را ملزم به تأیید و بارگذاری آن artifact می‌کند. در مقابل، existing-only به ارجاع‌های صریح GHCR در docker_e2e_bare_image/docker_e2e_functional_image نیاز دارد و هرگز چیزی نمی‌سازد یا push نمی‌کند. این pullهای registry برای هر تلاش از مهلت زمانی محدود 180 ثانیه‌ای استفاده می‌کنند تا یک جریان گیرکرده به‌جای مصرف بخش عمدهٔ مسیر بحرانی CI، سریعاً دوباره تلاش شود. پس از اعتبارسنجی موفق زمان‌بندی‌شده، openclaw-scheduled-live-checks.yml manifest تغییرناپذیر تصویر آزموده‌شده را به ناشر جداگانهٔ نوشتن بسته می‌دهد؛ فراخوان‌های فقط‌خواندنی انتشار و پیش‌انتشار هرگز از آن نویسنده عبور نمی‌کنند.

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

پوشش Docker انتشار، jobهای بخش‌بندی‌شدهٔ کوچک‌تری را با OPENCLAW_SKIP_DOCKER_BUILD=1 اجرا می‌کند تا هر بخش فقط نوع تصویر پشتیبانی‌شده توسط artifact موردنیاز خود را تأیید و بارگذاری کند (یا آن را تحت استفادهٔ مجدد صریح existing-only دریافت کند) و چندین lane را از طریق همان زمان‌بند وزن‌دار اجرا کند:

• OPENCLAW_DOCKER_ALL_PROFILE=release-path
• OPENCLAW_DOCKER_ALL_CHUNK=core | package-update-openai | package-update-anthropic | package-update-core | plugins-runtime-plugins | plugins-runtime-services | plugins-runtime-install-a..h | openwebui

بخش‌های فعلی 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. package-update-openai شامل lane زندهٔ بستهٔ Plugin مربوط به Codex است که بستهٔ کاندید OpenClaw را نصب می‌کند، Plugin مربوط به Codex را از codex_plugin_spec یا یک tarball با همان ref و با تأیید صریح نصب Codex CLI نصب می‌کند، پیش‌بررسی Codex CLI و نوبت‌های عامل در همان نشست را اجرا می‌کند، سپس یک نوبت با تفکر متوسط و بدون تلاش مجدد اجرا می‌کند که پیشرفت را ارسال می‌کند، ورودی‌های تصادفی فضای کاری را می‌خواند، artifact دقیق آن‌ها را می‌نویسد و تکمیل را ارسال می‌کند. plugins-runtime-core، plugins-runtime و plugins-integrations همچنان نام‌های مستعار تجمیعی Plugin/زمان اجرا باقی می‌مانند. نام مستعار lane در install-e2e همچنان نام مستعار تجمیعی اجرای مجدد دستی برای هر دو lane نصب‌کنندهٔ ارائه‌دهنده باقی می‌ماند.

OpenWebUI هرگاه پوشش stable یا کامل مسیر انتشار آن را درخواست کند، به‌صورت یک بخش مستقل openwebui روی runner اختصاصی Blacksmith با دیسک بزرگ اجرا می‌شود، حتی زمانی که گردش‌کار قابل‌استفادهٔ مجدد، jobهای پشتیبانی‌شده را به runnerهای میزبانی‌شده توسط GitHub هدایت می‌کند. جدا نگه‌داشتن دریافت تصویر خارجی مانع رقابت تصویر بزرگ با تصاویر مشترک بسته و Plugin در plugins-runtime-services می‌شود؛ بخش‌های تجمیعی قدیمی Plugin/زمان اجرا همچنان OpenWebUI را برای اجرای مجدد دستی سازگار در بر می‌گیرند. laneهای به‌روزرسانی کانال‌های همراه، برای خطاهای گذرای شبکهٔ npm یک‌بار دوباره تلاش می‌کنند.

هر بخش، .artifacts/docker-tests/ را همراه با گزارش‌های lane، زمان‌بندی‌ها، summary.json، failures.json، زمان‌بندی فازها، JSON برنامهٔ زمان‌بند، جدول‌های laneهای کند و فرمان‌های اجرای مجدد هر lane بارگذاری می‌کند. ورودی docker_lanes گردش‌کار، laneهای انتخاب‌شده را به‌جای jobهای بخش‌بندی‌شده روی تصاویر آماده‌شده برای همان اجرا، اجرا می‌کند؛ بنابراین اشکال‌زدایی lane ناموفق به یک job هدفمند Docker محدود می‌ماند؛ اگر lane انتخاب‌شده یک lane زندهٔ Docker باشد، job هدفمند تصویر آزمون زنده را برای آن اجرای مجدد به‌صورت محلی می‌سازد. کمک‌ابزار اجرای مجدد، SHA دقیق هدف انتخاب‌شده در artifact شکست را اعتبارسنجی می‌کند و dispatch دستی آن ref را دوباره بسته‌بندی می‌کند، زیرا tuple داخلی بستهٔ گردش‌کار قابل‌استفادهٔ مجدد بخشی از schema مربوط به workflow_dispatch نیست. فرمان‌های تولیدشده فقط زمانی ورودی‌های تصویر آماده‌شده و shared_image_policy=existing-only را شامل می‌شوند که آن ورودی‌ها توسط GHCR پشتیبانی شوند؛ برچسب‌های artifact محلی runner حذف می‌شوند تا یک runner تازه آن‌ها را دوباره بسازد. بازنویسی صریح هدف، ارجاع‌های بازیابی‌شدهٔ تصویر GHCR را حذف می‌کند، مگر اینکه artifact ثابت کند با بازنویسی مطابقت دارند. refهای تعریف گردش‌کار تولیدشده توسط artifact نیز حذف می‌شوند، زیرا شاخه‌های موقت انتشار کامل حذف می‌شوند؛ dispatch از شاخهٔ پیش‌فرض مخزن استفاده می‌کند، مگر اینکه اپراتور صراحتاً آن را بازنویسی کند.

pnpm test:docker:rerun <run-id>      # artifactهای Docker را بارگیری و فرمان‌های اجرای مجدد هدفمند ترکیبی/هر lane را چاپ کنیدpnpm test:docker:timings <summary>   # خلاصه‌های laneهای کند و مسیر بحرانی فازها

گردش‌کار زمان‌بندی‌شدهٔ زنده/E2E هر روز مجموعهٔ کامل Docker مسیر انتشار را اجرا می‌کند و پس از موفقیت، ناشر صریح را برای artifactهای دقیق تصاویر آزموده‌شده فراخوانی می‌کند.

پیش‌انتشار Plugin

Plugin Prerelease پوشش پرهزینه‌تری برای محصول/بسته است، بنابراین یک گردش‌کار جداگانه است که توسط Full Release Validation یا یک اپراتور به‌صورت صریح اجرا می‌شود. Pull requestهای عادی، pushهای main و اجراهای دستی مستقل CI آن مجموعه را غیرفعال نگه می‌دارند. این گردش‌کار آزمون‌های Pluginهای همراه را میان هشت worker افزونه متعادل می‌کند؛ آن jobهای shard افزونه، هم‌زمان حداکثر دو گروه پیکربندی Plugin را با یک worker از Vitest برای هر گروه و heap بزرگ‌تر Node اجرا می‌کنند تا دسته‌های Plugin با import سنگین، jobهای CI اضافی ایجاد نکنند. مسیر پیش‌انتشار Docker که فقط برای انتشار است (و با ورودی full_release_validation فعال می‌شود)، laneهای هدفمند Docker را در گروه‌های چهارتایی دسته‌بندی می‌کند تا برای jobهای یک تا سه‌دقیقه‌ای، ده‌ها runner رزرو نشود. این گردش‌کار همچنین یک artifact اطلاع‌رسان plugin-inspector-advisory را از @openclaw/plugin-inspector بارگذاری می‌کند؛ یافته‌های inspector ورودی triage هستند و gate مسدودکننده Plugin Prerelease را تغییر نمی‌دهند.

آزمایشگاه QA

آزمایشگاه QA دارای laneهای اختصاصی CI خارج از گردش‌کار اصلی با محدوده‌بندی هوشمند است. هم‌ارزی عامل‌محور در harnessهای گسترده QA و انتشار جای دارد، نه در یک گردش‌کار مستقل PR. هنگامی که هم‌ارزی باید همراه یک اجرای اعتبارسنجی گسترده انجام شود، از Full Release Validation همراه با rerun_group=qa-parity استفاده کنید.

• گردش‌کار QA-Lab - All Lanes هر شب در main و نیز با اجرای دستی اجرا می‌شود؛ این گردش‌کار jobهای هم‌ارزی mock و همچنین jobهای زنده Matrix، Telegram، Discord، WhatsApp و Slack را به‌صورت fan-out اجرا می‌کند. jobهای زنده از محیط qa-live-shared استفاده می‌کنند؛ Telegram، Discord، WhatsApp و Slack از leaseهای Convex استفاده می‌کنند، درحالی‌که Matrix اعتبارنامه‌های محلی یک‌بارمصرف فراهم می‌کند.

بررسی‌های انتشار، laneهای انتقال زنده Matrix و Telegram را با ارائه‌دهنده mock قطعی و مدل‌های واجد شرایط mock (mock-openai/gpt-5.6-luna و mock-openai/gpt-5.6-luna-alt) اجرا می‌کنند تا قرارداد کانال از تأخیر مدل زنده و راه‌اندازی عادی Plugin ارائه‌دهنده جدا بماند. Gateway انتقال زنده، جست‌وجوی حافظه را غیرفعال می‌کند، زیرا هم‌ارزی QA رفتار حافظه را جداگانه پوشش می‌دهد؛ اتصال ارائه‌دهنده نیز توسط مجموعه‌های جداگانه مدل زنده، ارائه‌دهنده بومی و ارائه‌دهنده Docker پوشش داده می‌شود.

gateهای زمان‌بندی‌شده و انتشار Matrix از میزبان مشترک مجموعه آزمایشگاه QA و adapter زنده همراه با سناریوهای انتشار استفاده می‌کنند. مقدار پیش‌فرض CLI و ورودی گردش‌کار دستی همچنان all است؛ اجراهای دستی all، پروفایل‌های transport، media، e2ee-smoke، e2ee-deep و e2ee-cli را به‌صورت fan-out اجرا می‌کنند تا اثبات 93 سناریویی در محدوده timeout هر job باقی بماند. اجراهای دستی متمرکز، fast، release یا transport را در یک job انتخاب می‌کنند.

OpenClaw Release Checks همچنین laneهای حیاتی انتشار آزمایشگاه QA را پیش از تأیید انتشار اجرا می‌کند؛ gate هم‌ارزی QA آن، بسته‌های candidate و baseline را به‌صورت jobهای lane موازی اجرا می‌کند، سپس هر دو artifact را برای مقایسه نهایی هم‌ارزی در یک job گزارش کوچک دانلود می‌کند.

برای PRهای عادی، به‌جای درنظرگرفتن هم‌ارزی به‌عنوان یک وضعیت الزامی، از شواهد CI/بررسی محدوده‌بندی‌شده پیروی کنید.

CodeQL

گردش‌کار CodeQL عمداً یک اسکنر امنیتی محدود برای گذر نخست است، نه پیمایش کامل مخزن. اجراهای روزانه، دستی، push روی main و guardهای Pull request غیردرافت، کد گردش‌کارهای Actions را همراه با پرخطرترین سطوح JavaScript/TypeScript با queryهای امنیتی با اطمینان بالا اسکن می‌کنند که به security-severity با شدت بالا/بحرانی محدود شده‌اند.

guard مربوط به Pull request سبک باقی می‌ماند: فقط برای تغییرات زیر .github/actions، .github/codeql، .github/workflows، packages، scripts، src یا مسیرهای runtime مربوط به Pluginهای همراهِ مالک پردازش آغاز می‌شود و همان ماتریس امنیتی با اطمینان بالا را مانند گردش‌کار زمان‌بندی‌شده اجرا می‌کند. CodeQL اندروید و macOS در پیش‌فرض‌های PR قرار ندارند.

دسته‌های امنیتی

shardهای امنیتی ویژه پلتفرم

• CodeQL Android Critical Security — shard امنیتی زمان‌بندی‌شده اندروید. برنامه اندروید را برای CodeQL به‌صورت دستی روی کوچک‌ترین runner لینوکس Blacksmith که بررسی سلامت گردش‌کار می‌پذیرد، build می‌کند. با نام /codeql-critical-security/android بارگذاری می‌شود.
• CodeQL macOS Critical Security — shard امنیتی هفتگی/دستی macOS. برنامه macOS را برای CodeQL روی Blacksmith macOS به‌صورت دستی build می‌کند، نتایج build وابستگی‌ها را از SARIF بارگذاری‌شده حذف می‌کند و با نام /codeql-critical-security/macos بارگذاری می‌شود. چون build در macOS حتی در حالت پاک نیز بخش عمده زمان اجرا را مصرف می‌کند، خارج از پیش‌فرض‌های روزانه نگه داشته شده است.

دسته‌های کیفیت بحرانی

CodeQL Critical Quality shard غیرامنیتی متناظر است. این shard فقط queryهای کیفیت JavaScript/TypeScript غیرامنیتی با شدت خطا را روی سطوح محدود و باارزش در runnerهای لینوکس میزبانی‌شده توسط GitHub اجرا می‌کند تا اسکن‌های کیفیت بودجه ثبت runner در Blacksmith را مصرف نکنند. guard مربوط به Pull request آن عمداً کوچک‌تر از پروفایل زمان‌بندی‌شده است: PRهای غیردرافت فقط shardهای متناظر با سطوحی را که لمس می‌کنند، از میان سیزده shard قابل‌مسیریابی PR اجرا می‌کنند — agent-runtime-boundary، channel-runtime-boundary، config-boundary، core-auth-secrets، gateway-runtime-boundary، mcp-process-runtime-boundary، memory-runtime-boundary، network-runtime-boundary، plugin-boundary، plugin-sdk-package-contract، plugin-sdk-reply-runtime، provider-runtime-boundary و session-diagnostics-boundary. ui-control-plane و web-media-runtime-boundary در اجراهای PR قرار ندارند. تغییرات پیکربندی CodeQL و گردش‌کار کیفیت، مجموعه کامل shardهای PR را اجرا می‌کنند (کلید shard مربوط به runtime شبکه بر اساس فایل‌های پیکربندی CodeQL خودش و مسیرهای منبع مالک شبکه عمل می‌کند).

اجرای دستی موارد زیر را می‌پذیرد:

profile=all|agent-runtime-boundary|config-boundary|core-auth-secrets|channel-runtime-boundary|gateway-runtime-boundary|memory-runtime-boundary|mcp-process-runtime-boundary|network-runtime-boundary|plugin-boundary|plugin-sdk-package-contract|plugin-sdk-reply-runtime|provider-runtime-boundary|session-diagnostics-boundary

پروفایل‌های محدود، hookهایی برای آموزش/تکرار هستند تا یک shard کیفیت به‌صورت مجزا اجرا شود.

کیفیت از امنیت جدا نگه داشته می‌شود تا یافته‌های کیفیت بدون مبهم‌کردن سیگنال امنیتی زمان‌بندی، اندازه‌گیری، غیرفعال یا گسترش داده شوند. گسترش CodeQL برای Swift، Python و Pluginهای همراه تنها پس از آن‌که پروفایل‌های محدود به زمان اجرا و سیگنال پایدار رسیدند، باید به‌صورت کار پیگیری محدوده‌بندی‌شده یا shardبندی‌شده دوباره افزوده شود.

گردش‌کارهای نگه‌داری

عامل مستندات

گردش‌کار Docs Agent یک lane نگه‌داری رویدادمحور Codex برای هم‌راستا نگه‌داشتن مستندات موجود با تغییرات اخیراً ادغام‌شده است. این گردش‌کار زمان‌بندی صرف ندارد: یک اجرای موفق CI مربوط به push غیربات روی main می‌تواند آن را فعال کند و اجرای دستی نیز می‌تواند آن را مستقیماً اجرا کند. فراخوانی‌های ناشی از اجرای گردش‌کار، زمانی رد می‌شوند که main جلو رفته باشد یا در یک ساعت گذشته اجرای ردنشده دیگری از عامل مستندات ایجاد شده باشد. هنگام اجرا، محدوده commit از SHA منبع آخرین عامل مستندات ردنشده تا main فعلی بازبینی می‌شود؛ بنابراین یک اجرای ساعتی می‌تواند همه تغییرات main را که از آخرین گذر مستندات انباشته شده‌اند، پوشش دهد.

عامل عملکرد آزمون

گردش‌کار Test Performance Agent یک مسیر نگه‌داری رویدادمحور Codex برای تست‌های کند است. این گردش‌کار زمان‌بندی صرف ندارد: اجرای موفق CI ناشی از push غیررباتی روی main می‌تواند آن را راه‌اندازی کند، اما اگر فراخوانی دیگری از نوع workflow-run در همان روز UTC قبلاً اجرا شده باشد یا در حال اجرا باشد، از آن صرف‌نظر می‌کند. اجرای دستی از این دروازهٔ فعالیت روزانه عبور می‌کند. این مسیر یک گزارش عملکرد گروه‌بندی‌شدهٔ Vitest برای مجموعهٔ کامل می‌سازد، به Codex اجازه می‌دهد به‌جای بازآرایی‌های گسترده فقط اصلاحات کوچک عملکردی در تست‌ها انجام دهد که پوشش را حفظ می‌کنند، سپس گزارش مجموعهٔ کامل را دوباره اجرا می‌کند و تغییراتی را که تعداد پایهٔ تست‌های موفق را کاهش دهند رد می‌کند. گزارش گروه‌بندی‌شده، زمان سپری‌شدهٔ هر پیکربندی و حداکثر RSS را در Linux و macOS ثبت می‌کند تا مقایسهٔ قبل و بعد، تغییرات حافظهٔ تست را در کنار تغییرات مدت‌زمان نشان دهد. اگر خط پایه تست‌های ناموفق داشته باشد، Codex فقط می‌تواند شکست‌های آشکار را اصلاح کند و گزارش مجموعهٔ کامل پس از اجرای عامل باید پیش از commit شدن هر چیزی موفق باشد. وقتی main پیش از ثبت push ربات جلو می‌رود، مسیر وصلهٔ اعتبارسنجی‌شده را rebase می‌کند، pnpm check:changed را دوباره اجرا می‌کند و push را مجدداً می‌آزماید؛ وصله‌های قدیمیِ دارای تداخل نادیده گرفته می‌شوند. این مسیر از Ubuntu میزبانی‌شده در GitHub استفاده می‌کند تا اکشن Codex بتواند همان رویکرد ایمنی حذف sudo عامل مستندات را حفظ کند.

PRهای تکراری پس از ادغام

گردش‌کار Duplicate PRs After Merge یک گردش‌کار دستی نگه‌دارنده برای پاک‌سازی موارد تکراری پس از ادغام است. حالت پیش‌فرض آن اجرای آزمایشی است و فقط زمانی PRهای صریحاً فهرست‌شده را می‌بندد که apply=true. پیش از ایجاد تغییر در GitHub، بررسی می‌کند که PR ادغام‌شده واقعاً merge شده باشد و هر مورد تکراری یا یک issue ارجاع‌شدهٔ مشترک داشته باشد یا دارای بخش‌های تغییریافتهٔ هم‌پوشان باشد.

gh workflow run duplicate-after-merge.yml \  -f landed_pr=70532 \  -f duplicate_prs='70530,70592' \  -f apply=true

دروازه‌های بررسی محلی و مسیریابی تغییرات

جغجغهٔ شمارش خط پایهٔ پیکربندی

pnpm config:docs:check رشد مستندنشدهٔ سطح پیکربندی و snapshotهای شمارش خراب یا قدیمی را رد می‌کند. وقتی تغییری بازبینی‌شده در محصول عمداً مسیرهایی به schema اضافه می‌کند، pnpm config:docs:gen را اجرا کنید، تغییرات تعداد core/channel/plugin و فایل‌های SHA-256 تولیدشده را بررسی کنید و افزایش آگاهانهٔ خط پایه را همراه با schema، راهنما، برچسب‌ها، مهاجرت و تست‌ها commit کنید. برای دور زدن جغجغه، فایل شمارش را دستی ویرایش نکنید.

نویسندگان پیکربندی باید برگ‌های جدید را برای تنظیمات نیز سطح‌بندی کنند. advanced: false یا advanced: true را در برگ اضافه کنید، یا کلید را زیر نیایی قرار دهید که همهٔ فرزندان باید سطح آن را به ارث ببرند. ریشه‌های طبقه‌بندی‌نشده در تست کیفیت schema با نمونه‌های آمادهٔ قابل کپی ناموفق می‌شوند؛ مسیرهای بدون نیا به‌طور پیش‌فرض پیشرفته هستند. snapshot گزینش‌شدهٔ برگ‌های رایج، تغییرات عمدی سطح را در بازبینی نمایان می‌کند.

منطق محلی مسیرهای تغییریافته در scripts/changed-lanes.mjs قرار دارد و توسط scripts/check-changed.mjs اجرا می‌شود. این دروازهٔ بررسی محلی دربارهٔ مرزهای معماری از محدودهٔ گستردهٔ پلتفرم CI سخت‌گیرانه‌تر است:

• تغییرات کد تولیدی core، بررسی نوع کد تولیدی core و تست core را به‌همراه lint/guardهای core اجرا می‌کنند؛
• تغییرات صرفاً مربوط به تست core فقط بررسی نوع تست core را به‌همراه lint هسته اجرا می‌کنند؛
• تغییرات کد تولیدی افزونه، بررسی نوع کد تولیدی افزونه و تست افزونه را به‌همراه lint افزونه اجرا می‌کنند؛
• تغییرات صرفاً مربوط به تست افزونه، بررسی نوع تست افزونه را به‌همراه lint افزونه اجرا می‌کنند؛
• تغییرات عمومی Plugin SDK یا قرارداد Plugin دامنه را به بررسی نوع افزونه گسترش می‌دهند، زیرا افزونه‌ها به آن قراردادهای core وابسته‌اند (پویش‌های افزونهٔ Vitest همچنان کار تستی صریح باقی می‌مانند)؛
• افزایش‌های نسخه که فقط فرادادهٔ انتشار را تغییر می‌دهند، بررسی‌های هدفمند نسخه/پیکربندی/وابستگی ریشه را اجرا می‌کنند؛
• تغییرات ناشناختهٔ ریشه/پیکربندی برای ایمنی در همهٔ مسیرهای بررسی ناموفق می‌شوند.

مسیریابی محلی تست‌های تغییریافته در scripts/test-projects.test-support.mjs قرار دارد و عمداً کم‌هزینه‌تر از check:changed است: ویرایش مستقیم تست‌ها خود آن‌ها را اجرا می‌کند، ویرایش کد منبع ابتدا نگاشت‌های صریح و سپس تست‌های هم‌سطح و وابستگان گراف import را ترجیح می‌دهد. پیکربندی مشترک تحویل اتاق گروهی یکی از نگاشت‌های صریح است: تغییرات در پیکربندی پاسخ قابل‌مشاهدهٔ گروه، حالت تحویل پاسخ منبع یا prompt سیستمی ابزار پیام از مسیر تست‌های پاسخ core به‌همراه رگرسیون‌های تحویل Discord و Slack عبور می‌کنند تا تغییر یک پیش‌فرض مشترک پیش از نخستین push مربوط به PR ناموفق شود. فقط زمانی از OPENCLAW_TEST_CHANGED_BROAD=1 pnpm test:changed استفاده کنید که تغییر چنان سراسر harness را در بر می‌گیرد که مجموعهٔ نگاشت‌شدهٔ کم‌هزینه نمایندهٔ قابل‌اعتمادی نیست.

اعتبارسنجی Testbox

Crabbox پوشش‌دهندهٔ remote-box متعلق به مخزن برای اثبات نگه‌دارنده در Linux است. نشست‌های عامل فقط برای منبع مورداعتماد و هنگامی که نصب وابستگی‌های موجود آماده است، یک یا چند تست متمرکز و بررسی استاتیک کم‌هزینه را محلی نگه می‌دارند. آن‌ها برای مجموعه‌های بزرگ‌تر و کارهای محاسباتی سنگین، از جمله buildها، بررسی نوع، گسترش lint، Docker، مسیرهای بسته، E2E، اثبات زنده و برابری با CI از Crabbox استفاده می‌کنند. اثبات سنگین نگه‌دارندهٔ مورداعتماد به‌طور پیش‌فرض از blacksmith-testbox استفاده می‌کند و .crabbox.yaml اکنون به‌طور پیش‌فرض از آن استفاده می‌کند. گردش‌کار پیکربندی‌شدهٔ آن اطلاعات اصالت‌سنجی provider و عامل را بارگذاری می‌کند؛ بنابراین کد نامطمئن مشارکت‌کننده یا fork باید در عوض از CI بدون secret مربوط به fork یا Crabbox مستقیم و پاک‌سازی‌شدهٔ AWS استفاده کند. اجراهای پاک‌سازی‌شدهٔ AWS، CRABBOX_ENV_ALLOW=CI را تنظیم می‌کنند، --no-hydrate را ارسال می‌کنند و از یک HOME موقت و تازه روی میزبان دور استفاده می‌کنند؛ این کار مانع می‌شود فهرست مجاز OPENCLAW_* مخزن و پروفایل‌های auth موجود به کد نامطمئن دسترسی پیدا کنند. آن‌ها از lease تازه آماده‌شده‌ای استفاده می‌کنند که به همان منبع نامطمئن اختصاص یافته است، و هرگز از lease مورداعتماد یا قبلاً بارگذاری‌شده استفاده نمی‌کنند. یک فایل اجرایی نصب‌شده و مورداعتماد Crabbox را از checkout پاک و مورداعتماد main اجرا کنید و فقط PR راه دور را با --fresh-pr دریافت کنید؛ هرگز پوشش‌دهنده یا پیکربندی checkout نامطمئن را محلی اجرا نکنید. CRABBOX_AWS_INSTANCE_PROFILE را unset کنید و مگر اینکه مقدار resolve‌شدهٔ aws.instanceProfile خالی باشد، با حالت بسته و ناموفق ادامه دهید. پیش از هر install/test، از ابزارهای مورداعتماد با مسیر مطلق استفاده کنید تا توکن IMDSv2 الزامی باشد، ثابت کنید endpoint اطلاعات اصالت‌سنجی IAM مقدار 404 بازمی‌گرداند و git rev-parse HEAD راه دور را با SHA کامل head بازبینی‌شدهٔ PR مقایسه کنید. lease را به آن SHA متصل کنید و در صورت تغییر head آن را متوقف و دوباره آماده کنید. scripts/crabbox-untrusted-bootstrap.sh مورداعتماد را از main پاک همراه با --fresh-pr بارگذاری کنید؛ این فایل Node/pnpm سنجاق‌شده را نصب می‌کند، SHA و سنجاق مدیر بسته را تأیید می‌کند، HOME را ایزوله می‌کند، وابستگی‌ها را نصب می‌کند و سپس تست درخواستی را اجرا می‌کند. همهٔ overrideهای CRABBOX_TAILSCALE* را unset کنید، --network public --tailscale=false را اجباری کنید، پرچم‌های exit-node/LAN را پاک کنید و پیش از بارگذاری هر اسکریپت، الزام کنید crabbox inspect شبکهٔ عمومی بدون وضعیت Tailscale را گزارش دهد. ظرفیت تحت مالکیت AWS/Hetzner نیز برای قطعی‌های Blacksmith، مشکلات سهمیه یا تست صریح ظرفیت تحت مالکیت، گزینهٔ جایگزین باقی می‌ماند.

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

اجراهای Blacksmith با پشتیبانی Crabbox، Testboxهای یک‌بارمصرف را آماده، دریافت، همگام‌سازی، اجرا، گزارش و پاک‌سازی می‌کنند. بررسی سلامت داخلی همگام‌سازی وقتی git status --short روی میزبان همگام‌شده دست‌کم 200 حذف فایل ردیابی‌شده نشان دهد، سریعاً ناموفق می‌شود؛ این وضعیت ناپدید شدن فایل‌های ریشه مانند pnpm-lock.yaml را تشخیص می‌دهد. برای PRهایی با حذف گستردهٔ عمدی، CRABBOX_ALLOW_MASS_DELETIONS=1 را برای فرمان راه دور تنظیم کنید.

Crabbox همچنین یک فراخوانی محلی CLI مربوط به Blacksmith را که بیش از پنج دقیقه بدون خروجی پس از همگام‌سازی در مرحلهٔ sync باقی بماند خاتمه می‌دهد. برای غیرفعال کردن این guard، CRABBOX_BLACKSMITH_SYNC_TIMEOUT_MS=0 را تنظیم کنید، یا برای diffهای محلی غیرمعمول و بزرگ از مقدار بزرگ‌تری بر حسب میلی‌ثانیه استفاده کنید.

پیش از نخستین اجرا، پوشش‌دهنده را از ریشهٔ مخزن بررسی کنید:

pnpm crabbox:run -- --help | sed -n '1,120p'

پوشش‌دهندهٔ مخزن یک فایل اجرایی قدیمی Crabbox را که provider انتخاب‌شده را اعلام نمی‌کند نمی‌پذیرد، و اجراهای مبتنی بر Blacksmith به Crabbox نسخهٔ 0.22.0 یا جدیدتر نیاز دارند تا پوشش‌دهنده رفتار فعلی همگام‌سازی، صف و پاک‌سازی Testbox را دریافت کند. در worktreeهای Codex یا checkoutهای پیوندی/تنک، از اسکریپت محلی pnpm crabbox:run پرهیز کنید، زیرا pnpm ممکن است پیش از شروع Crabbox وابستگی‌ها را تطبیق دهد؛ در عوض پوشش‌دهندهٔ node را مستقیماً فراخوانی کنید:

node scripts/crabbox-wrapper.mjs run --provider blacksmith-testbox --timing-json --shell -- "pnpm test <path-or-filter>"

هنگام استفاده از checkout هم‌سطح، پیش از کار اندازه‌گیری زمان یا اثبات، فایل اجرایی محلی نادیده‌گرفته‌شده را دوباره build کنید:

version="$(git -C ../crabbox describe --tags --always --dirty | sed 's/^v//')" \  && go build -C ../crabbox -trimpath -ldflags "-s -w -X github.com/openclaw/crabbox/internal/cli.version=${version}" -o bin/crabbox ./cmd/crabbox

بلوک blacksmith: در .crabbox.yaml از قبل مقادیر پیش‌فرض سازمان، گردش‌کار، job و ref را سنجاق می‌کند، بنابراین پرچم‌های صریح زیر اختیاری هستند. دروازهٔ تغییرات:

pnpm crabbox:run -- --provider blacksmith-testbox \  --blacksmith-org openclaw \  --blacksmith-workflow .github/workflows/ci-check-testbox.yml \  --blacksmith-job check \  --blacksmith-ref main \  --idle-timeout 90m \  --ttl 240m \  --timing-json \  --shell -- \  "corepack pnpm check:changed"

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

pnpm crabbox:run -- --provider blacksmith-testbox \  --idle-timeout 90m \  --ttl 240m \  --timing-json \  --shell -- \  "corepack pnpm test <path-or-filter>"

مجموعهٔ کامل:

pnpm crabbox:run -- --provider blacksmith-testbox \  --idle-timeout 90m \  --ttl 240m \  --timing-json \  --shell -- \  "corepack pnpm test"

خلاصهٔ JSON نهایی را بخوانید. فیلدهای مفید عبارت‌اند از provider، leaseId، syncDelegated، exitCode، commandMs و totalMs. برای اجراهای واگذارشدهٔ Blacksmith Testbox، کد خروج پوشش‌دهندهٔ Crabbox و خلاصهٔ JSON نتیجهٔ فرمان هستند. اجرای مرتبط GitHub Actions مالک بارگذاری و زنده‌نگه‌داشتن است؛ اگر Testbox پس از بازگشت فرمان SSH به‌طور خارجی متوقف شود، ممکن است با cancelled پایان یابد. این وضعیت را یک اثر جانبی پاک‌سازی/وضعیت در نظر بگیرید، مگر اینکه exitCode پوشش‌دهنده غیرصفر باشد یا خروجی فرمان یک تست ناموفق را نشان دهد. اجراهای یک‌بارمصرف Crabbox مبتنی بر Blacksmith باید Testbox را به‌طور خودکار متوقف کنند؛ اگر اجرایی قطع شد یا پاک‌سازی نامشخص بود، میزبان‌های فعال را بررسی کنید و فقط میزبان‌هایی را که خودتان ایجاد کرده‌اید متوقف کنید:

blacksmith testbox list --allblacksmith testbox status --id <tbx_id>blacksmith testbox stop --id <tbx_id>

فقط زمانی از استفادهٔ مجدد بهره ببرید که عمداً به چند فرمان روی همان میزبان بارگذاری‌شده نیاز دارید:

node scripts/crabbox-wrapper.mjs run --provider blacksmith-testbox --id <tbx_id> --timing-json --shell -- "corepack pnpm test <path-or-filter>"pnpm crabbox:stop -- <tbx_id>

lease را دوباره استفاده کنید، نه منبع قدیمی را. --no-sync را حذف کنید تا هر اجرا checkout فعلی را بارگذاری کند؛ فقط برای اجرای مجدد عمدی یک درخت بدون تغییر و از قبل همگام‌شده از آن استفاده کنید. کد نامطمئن مشارکت‌کننده/fork باید برای هر فرمان از CRABBOX_ENV_ALLOW=CI، --provider aws --no-hydrate و یک HOME موقت و تازه روی میزبان راه دور استفاده کند؛ پیش از تست، وابستگی‌ها را داخل همان فرمان پاک‌سازی‌شده نصب کنید. فقط یک lease تازه آماده‌شده و اختصاص‌یافته به همان منبع نامطمئن را دوباره استفاده کنید؛ هرگز از lease مورداعتماد یا قبلاً بارگذاری‌شده استفاده نکنید. هرگز پوشش‌دهنده یا پیکربندی checkout نامطمئن را محلی اجرا نکنید: فایل اجرایی نصب‌شده و مورداعتماد Crabbox را از main پاک و مورداعتماد اجرا کنید و در هر اجرا --fresh-pr را ارسال کنید. CRABBOX_AWS_INSTANCE_PROFILE را unset نگه دارید، پروفایل instance resolve‌شده و غیرخالی را رد کنید، اثبات مورداعتماد نبود نقش IMDS راه دور را الزامی کنید و پیش از install/test، SHA مربوط به head بازبینی‌شده را تأیید کنید. lease را به آن SHA متصل کنید؛ پس از هر تغییر head، آن را متوقف و دوباره آماده کنید. اگر PR راه دور وجود ندارد، از CI بدون secret مربوط به fork استفاده کنید. برای منبع نامطمئن هرگز hydrate-github یا گردش‌کار Blacksmith با اطلاعات اصالت‌سنجی بارگذاری‌شده را انتخاب نکنید.

اگر Crabbox لایهٔ خراب است اما خود Blacksmith کار می‌کند، از Blacksmith مستقیم فقط برای تشخیص‌هایی مانند list، status و پاک‌سازی استفاده کنید. پیش از آنکه اجرای مستقیم Blacksmith را اثبات نگه‌دارنده در نظر بگیرید، مسیر Crabbox را اصلاح کنید.

اگر blacksmith testbox list --all و blacksmith testbox status کار می‌کنند اما warmupهای جدید پس از چند دقیقه بدون IP یا URL اجرای Actions در وضعیت queued می‌مانند، آن را ناشی از فشار ارائه‌دهنده Blacksmith، صف، صورت‌حساب یا محدودیت‌های سازمان در نظر بگیرید. شناسه‌های در صفی را که ایجاد کرده‌اید متوقف کنید، Testboxهای بیشتری راه‌اندازی نکنید و درحالی‌که فردی داشبورد، صورت‌حساب و محدودیت‌های سازمان Blacksmith را بررسی می‌کند، اثبات را به مسیر ظرفیت تحت مالکیت Crabbox در زیر منتقل کنید.

تنها زمانی به ظرفیت تحت مالکیت Crabbox منتقل شوید که Blacksmith از دسترس خارج است، با محدودیت سهمیه مواجه است، محیط موردنیاز را ندارد یا ظرفیت تحت مالکیت صراحتاً هدف است:

CRABBOX_CAPACITY_REGIONS=eu-west-1,eu-west-2,eu-central-1,us-east-1,us-west-2 \  pnpm crabbox:warmup -- --provider aws --class standard --market on-demand --idle-timeout 90mpnpm crabbox:hydrate -- --provider aws --id <cbx_id-or-slug>pnpm crabbox:run -- --provider aws --id <cbx_id-or-slug> --timing-json --shell -- "pnpm check:changed"pnpm crabbox:stop -- --provider aws <cbx_id-or-slug>

هنگام فشار بر AWS، از class=beast استفاده نکنید، مگر اینکه کار واقعاً به CPU رده 48xlarge نیاز داشته باشد. درخواست beast از 192 vCPU آغاز می‌شود و ساده‌ترین راه برای عبور از سهمیه منطقه‌ای EC2 Spot یا On-Demand Standard است. .crabbox.yaml تحت مالکیت مخزن به‌طور پیش‌فرض از class: standard، بازار on-demand و capacity.hints: true استفاده می‌کند تا اجاره‌های واسطه‌ای AWS منطقه/بازار انتخاب‌شده، فشار سهمیه، بازگشت به Spot و هشدارهای رده پرفشار را چاپ کنند. برای بررسی‌های گسترده‌تر و سنگین‌تر از fast استفاده کنید، از large تنها پس از کافی‌نبودن standard/fast و از beast فقط برای مسیرهای استثنایی وابسته به CPU مانند ماتریس‌های Docker مجموعه‌آزمون کامل یا همه Pluginها، اعتبارسنجی صریح انتشار/مسدودکننده یا پروفایل‌گیری کارایی با تعداد هسته بالا استفاده کنید. برای pnpm check:changed، آزمون‌های متمرکز، کار صرفاً مستنداتی، lint/typecheck معمولی، بازتولیدهای کوچک E2E یا عیب‌یابی قطعی Blacksmith از beast استفاده نکنید. برای تشخیص ظرفیت از --market on-demand استفاده کنید تا نوسان بازار Spot با سیگنال آمیخته نشود.

.crabbox.yaml مالک پیش‌فرض‌های ارائه‌دهنده، همگام‌سازی و آماده‌سازی GitHub Actions است. همگام‌سازی Crabbox هرگز .git را منتقل نمی‌کند؛ بنابراین checkout آماده‌شده Actions به‌جای همگام‌سازی remoteها و مخازن آبجکت محلی نگه‌دارنده، فراداده Git راه‌دور خود را حفظ می‌کند و پیکربندی مخزن علاوه‌براین مصنوعات محلی زمان اجرا/ساخت (مانند .artifacts و گزارش‌های آزمون) را که هرگز نباید منتقل شوند مستثنا می‌کند. .github/workflows/crabbox-hydrate.yml مالک checkout، راه‌اندازی Node/pnpm، واکشی origin/main و تحویل محیط غیرمحرمانه برای فرمان‌های crabbox run --id <cbx_id> در ابر تحت مالکیت است.

مرتبط

• نمای کلی نصب
• کانال‌های توسعه