परीक्षण: अपडेट और plugins

अपडेट और Plugin सत्यापन के लिए जाँच-सूची: साबित करें कि इंस्टॉल योग्य पैकेज वास्तविक उपयोगकर्ता स्थिति को अपडेट कर सकता है, doctor के माध्यम से पुरानी लेगेसी स्थिति की मरम्मत कर सकता है, और फिर भी हर समर्थित स्रोत से Plugin इंस्टॉल, लोड, अपडेट और अनइंस्टॉल कर सकता है।

व्यापक टेस्ट रनर मानचित्र के लिए, परीक्षण देखें। लाइव प्रोवाइडर कुंजियों और नेटवर्क का उपयोग करने वाले सुइट के लिए, लाइव परीक्षण देखें।

हम क्या सुरक्षित रखते हैं

• पैकेज टारबॉल पूर्ण है, उसमें मान्य dist/postinstall-inventory.json है, और वह अनपैक की गई रिपॉज़िटरी फ़ाइलों पर निर्भर नहीं है।
• उपयोगकर्ता कॉन्फ़िगरेशन, एजेंट, सत्र, वर्कस्पेस, Plugin अनुमत-सूचियाँ या चैनल कॉन्फ़िगरेशन खोए बिना किसी पुराने प्रकाशित पैकेज से उम्मीदवार पैकेज पर जा सकता है।
• openclaw doctor --fix --non-interactive लेगेसी सफ़ाई और मरम्मत पथों का स्वामी है। स्टार्टअप को पुराने Plugin स्थिति के लिए छिपे हुए संगतता माइग्रेशन नहीं बढ़ाने चाहिए।
• Plugin इंस्टॉल स्थानीय डायरेक्टरी, git रिपॉज़िटरी, npm पैकेज और ClawHub रजिस्ट्री पथ से काम करते हैं।
• Plugin की npm निर्भरताएँ प्रति Plugin एक प्रबंधित npm प्रोजेक्ट में इंस्टॉल होती हैं, भरोसा करने से पहले स्कैन की जाती हैं, और Plugin अनइंस्टॉल के दौरान npm uninstall के माध्यम से हटाई जाती हैं, ताकि होइस्ट की गई निर्भरताएँ शेष न रहें।
• कुछ भी न बदलने पर Plugin अपडेट कोई कार्रवाई नहीं करता: इंस्टॉल रिकॉर्ड, समाधान किया गया स्रोत, इंस्टॉल की गई निर्भरता संरचना और सक्षम स्थिति अक्षुण्ण रहते हैं।

विकास के दौरान स्थानीय प्रमाण

सीमित दायरे से शुरू करें:

pnpm changed:lanes --jsonpnpm check:changedpnpm test:changed

Plugin इंस्टॉल, अनइंस्टॉल, निर्भरता या पैकेज-इन्वेंटरी परिवर्तनों के लिए, संपादित सीमांत को कवर करने वाले केंद्रित परीक्षण भी चलाएँ:

pnpm test src/plugins/uninstall.test.ts src/infra/package-dist-inventory.test.ts test/scripts/package-acceptance-workflow.test.ts

किसी पैकेज Docker लेन द्वारा टारबॉल का उपयोग करने से पहले, पैकेज आर्टिफ़ैक्ट को प्रमाणित करें:

pnpm release:check

release:check कॉन्फ़िगरेशन/दस्तावेज़/API अंतर जाँच चलाता है (कॉन्फ़िगरेशन स्कीमा, कॉन्फ़िगरेशन दस्तावेज़ बेसलाइन, Plugin SDK API अनुबंध मैनिफ़ेस्ट और एक्सपोर्ट, Plugin संस्करण/इन्वेंटरी), पैकेज वितरण इन्वेंटरी लिखता है, npm pack --dry-run चलाता है, प्रतिबंधित पैक की गई फ़ाइलों को अस्वीकार करता है, टारबॉल को अस्थायी प्रीफ़िक्स में इंस्टॉल करता है, पोस्टइंस्टॉल चलाता है और बंडल किए गए चैनल एंट्रीपॉइंट का स्मोक परीक्षण करता है।

Docker लेन

Docker लेन उत्पाद-स्तरीय प्रमाण हैं। वे Linux कंटेनरों के भीतर एक वास्तविक पैकेज इंस्टॉल या अपडेट करते हैं और CLI कमांड, Gateway स्टार्टअप, HTTP प्रोब, RPC स्थिति और फ़ाइल-सिस्टम स्थिति के माध्यम से व्यवहार की पुष्टि करते हैं।

पुनरावृत्ति करते समय केंद्रित लेन का उपयोग करें:

pnpm test:docker:pluginspnpm test:docker:plugin-lifecycle-matrixpnpm test:docker:plugin-updatepnpm test:docker:upgrade-survivorpnpm test:docker:published-upgrade-survivorpnpm test:docker:update-restart-authpnpm test:docker:update-migration

महत्वपूर्ण लेन:

• test:docker:plugins Plugin इंस्टॉल स्मोक, स्थानीय फ़ोल्डर इंस्टॉल, स्थानीय फ़ोल्डर अपडेट छोड़ने का व्यवहार, पहले से इंस्टॉल निर्भरताओं वाले स्थानीय फ़ोल्डर, file: पैकेज इंस्टॉल, CLI निष्पादन के साथ git इंस्टॉल, git मूविंग-रेफ़ अपडेट, होइस्ट की गई ट्रांज़िटिव निर्भरताओं के साथ npm रजिस्ट्री इंस्टॉल, बिना बदलाव वाले npm अपडेट, विकृत npm पैकेज मेटाडेटा की अस्वीकृति, स्थानीय ClawHub फ़िक्स्चर इंस्टॉल और बिना बदलाव वाले अपडेट, मार्केटप्लेस अपडेट व्यवहार और Claude-बंडल सक्षम करना/निरीक्षण कवर करता है। ClawHub ब्लॉक को स्व-निहित/ऑफ़लाइन रखने के लिए OPENCLAW_PLUGINS_E2E_CLAWHUB=0 सेट करें।
• test:docker:plugin-lifecycle-matrix उम्मीदवार पैकेज को एक खाली कंटेनर में इंस्टॉल करता है, किसी npm Plugin को इंस्टॉल, निरीक्षण, अक्षम करना, सक्षम करना, स्पष्ट अपग्रेड, स्पष्ट डाउनग्रेड और Plugin कोड हटाने के बाद अनइंस्टॉल तक चलाता है। यह प्रत्येक चरण के RSS और CPU मेट्रिक्स लॉग करता है।
• test:docker:plugin-update सत्यापित करता है कि अपरिवर्तित इंस्टॉल किया गया Plugin openclaw plugins update के दौरान दोबारा इंस्टॉल नहीं होता या इंस्टॉल मेटाडेटा नहीं खोता।
• test:docker:upgrade-survivor एक अव्यवस्थित पुराने-उपयोगकर्ता फ़िक्स्चर पर उम्मीदवार टारबॉल इंस्टॉल करता है, पैकेज अपडेट और गैर-इंटरैक्टिव डॉक्टर चलाता है, फिर लूपबैक Gateway शुरू करता है और स्थिति संरक्षण की जाँच करता है।
• test:docker:published-upgrade-survivor पहले प्रकाशित बेसलाइन इंस्टॉल करता है, उसे अंतर्निर्मित openclaw config set रेसिपी के माध्यम से कॉन्फ़िगर करता है, उसे उम्मीदवार टारबॉल पर अपडेट करता है, डॉक्टर चलाता है, लेगेसी सफ़ाई जाँचता है, Gateway शुरू करता है और /healthz, /readyz तथा RPC स्थिति को प्रोब करता है।
• test:docker:update-restart-auth उम्मीदवार पैकेज इंस्टॉल करता है, प्रबंधित टोकन-प्रमाणीकरण Gateway शुरू करता है, openclaw update --yes --json के लिए कॉलर Gateway प्रमाणीकरण एनवायरनमेंट को अनसेट करता है और सामान्य प्रोब से पहले उम्मीदवार अपडेट कमांड द्वारा Gateway पुनः आरंभ किए जाने की अपेक्षा करता है।
• test:docker:update-migration अधिक सफ़ाई वाला प्रकाशित-अपडेट लेन है। यह कॉन्फ़िगर की गई Discord/Telegram-शैली की उपयोगकर्ता स्थिति से शुरू होता है, बेसलाइन डॉक्टर चलाता है ताकि कॉन्फ़िगर की गई Plugin निर्भरताओं को अस्तित्व में आने का अवसर मिले, कॉन्फ़िगर किए गए पैकेज्ड Plugin के लिए लेगेसी Plugin निर्भरता अवशेष जोड़ता है, उम्मीदवार टारबॉल पर अपडेट करता है और अपडेट के बाद डॉक्टर से लेगेसी निर्भरता रूट हटाने की अपेक्षा करता है।

उपयोगी प्रकाशित-अपग्रेड सर्वाइवर प्रकार:

OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC=openclaw@2026.4.23 \OPENCLAW_UPGRADE_SURVIVOR_SCENARIO=versioned-runtime-deps \pnpm test:docker:published-upgrade-survivor OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC=openclaw@latest \OPENCLAW_UPGRADE_SURVIVOR_SCENARIO=bootstrap-persona \pnpm test:docker:published-upgrade-survivor

उपलब्ध परिदृश्य: base, acpx-openclaw-tools-bridge, feishu-channel, bootstrap-persona, channel-post-core-restore, plugin-deps-cleanup, configured-plugin-installs, stale-source-plugin-shadow, tilde-log-path और versioned-runtime-deps। समेकित रन में, OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS=reported-issues (उपनाम far-reaching) कॉन्फ़िगर किए गए Plugin इंस्टॉल माइग्रेशन सहित सभी परिदृश्यों में विस्तृत होता है।

पूर्ण अपडेट माइग्रेशन को जानबूझकर पूर्ण रिलीज़ CI से अलग रखा गया है। जब रिलीज़ संबंधी प्रश्न यह हो कि “क्या 2026.4.23 से अब तक की हर प्रकाशित स्थिर रिलीज़ इस उम्मीदवार पर अपडेट होकर Plugin निर्भरता अवशेष साफ़ कर सकती है?”, तब मैन्युअल Update Migration वर्कफ़्लो का उपयोग करें:

gh workflow run update-migration.yml \  --ref main \  -f workflow_ref=main \  -f package_ref=main \  -f baselines=all-since-2026.4.23 \  -f scenarios=plugin-deps-cleanup

पैकेज स्वीकृति

पैकेज स्वीकृति GitHub-मूल पैकेज गेट है। यह एक उम्मीदवार पैकेज को package-under-test टारबॉल में समाधान करता है, संस्करण और SHA-256 रिकॉर्ड करता है, फिर ठीक उसी टारबॉल के विरुद्ध पुनः उपयोग योग्य Docker E2E लेन चलाता है। वर्कफ़्लो हार्नेस रेफ़ पैकेज स्रोत रेफ़ से अलग होता है, ताकि वर्तमान परीक्षण तर्क पुरानी विश्वसनीय रिलीज़ का सत्यापन कर सके।

उम्मीदवार स्रोत:

• source=npm: openclaw@extended-stable, openclaw@beta, openclaw@latest या किसी सटीक प्रकाशित संस्करण को सत्यापित करें।
• source=ref: चयनित वर्तमान हार्नेस से किसी विश्वसनीय ब्रांच, टैग या कमिट को पैक करें।
• source=url: आवश्यक package_sha256 के साथ सार्वजनिक HTTPS टारबॉल सत्यापित करें। यह पथ URL क्रेडेंशियल, गैर-डिफ़ॉल्ट HTTPS पोर्ट, निजी/आंतरिक होस्टनाम या DNS/IP परिणाम, विशेष-उपयोग IP स्पेस और असुरक्षित रीडायरेक्ट को अस्वीकार करता है।
• source=trusted-url: अनुरक्षक-स्वामित्व वाली .github/package-trusted-sources.json नीति के विरुद्ध आवश्यक package_sha256 और trusted_source_id वाले HTTPS टारबॉल को सत्यापित करें। इनपुट-स्तरीय निजी-अनुमति स्विच से source=url को कमज़ोर करने के बजाय एंटरप्राइज़/निजी मिरर के लिए इसका उपयोग करें। नीति द्वारा कॉन्फ़िगर किए जाने पर बियरर प्रमाणीकरण नियत OPENCLAW_TRUSTED_PACKAGE_TOKEN सीक्रेट का उपयोग करता है।
• source=artifact: किसी अन्य Actions रन द्वारा अपलोड किए गए टारबॉल का पुनः उपयोग करें।

पूर्ण रिलीज़ सत्यापन डिफ़ॉल्ट रूप से समाधान किए गए रिलीज़ SHA से निर्मित source=artifact का उपयोग करता है। प्रकाशन के बाद के प्रमाण के लिए, package_acceptance_package_spec=openclaw@YYYY.M.PATCH पास करें ताकि वही अपग्रेड मैट्रिक्स भेजे गए npm पैकेज को लक्ष्य बनाए।

रिलीज़ जाँच पैकेज स्वीकृति को पैकेज/अपडेट/पुनः आरंभ/Plugin सेट के साथ कॉल करती हैं:

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

जब रिलीज़ सोक सक्षम हो (release_profile=stable और full के लिए बलपूर्वक सक्षम), तो वे यह भी पास करती हैं:

published_upgrade_survivor_baselines=last-stable-4 2026.4.23 2026.5.2 2026.4.15published_upgrade_survivor_scenarios=reported-issuestelegram_mode=mock-openai

इससे पैकेज माइग्रेशन, अपडेट चैनल स्विचिंग, दूषित प्रबंधित-Plugin सहनशीलता, पुरानी Plugin निर्भरता सफ़ाई, ऑफ़लाइन Plugin कवरेज, Plugin अपडेट व्यवहार और Telegram पैकेज QA एक ही समाधान किए गए आर्टिफ़ैक्ट पर बने रहते हैं, और डिफ़ॉल्ट रिलीज़ पैकेज गेट को प्रत्येक प्रकाशित रिलीज़ पर चलने की आवश्यकता नहीं पड़ती।

last-stable-4 npm पर प्रकाशित चार नवीनतम स्थिर OpenClaw रिलीज़ में समाधान होता है। रिलीज़ पैकेज स्वीकृति 2026.4.23 को प्रथम Plugin-अपडेट संगतता सीमा, 2026.5.2 को Plugin-आर्किटेक्चर परिवर्तन सीमा और 2026.4.15 को पुराने 2026.4.1x प्रकाशित-अपडेट बेसलाइन के रूप में पिन करती है; समाधानकर्ता उन पिनों को डिडुप्लिकेट करता है जो पहले से नवीनतम चार में हैं। व्यापक प्रकाशित अपडेट माइग्रेशन कवरेज के लिए, पूर्ण रिलीज़ CI के बजाय अलग अपडेट माइग्रेशन वर्कफ़्लो में all-since-2026.4.23 का उपयोग करें। जब आपको लेगेसी पूर्व-तिथि एंकर सहित व्यापक मैन्युअल नमूना चाहिए, तब release-history उपलब्ध रहता है।

जब अनेक प्रकाशित-अपग्रेड सर्वाइवर बेसलाइन चुनी जाती हैं, तो पुनः उपयोग योग्य Docker वर्कफ़्लो प्रत्येक बेसलाइन को उसके अपने लक्षित रनर जॉब में शार्ड करता है। प्रत्येक बेसलाइन शार्ड फिर भी चयनित परिदृश्य सेट चलाता है, लेकिन लॉग और आर्टिफ़ैक्ट प्रति-बेसलाइन बने रहते हैं और कुल समय एक बड़े क्रमिक जॉब के बजाय सबसे धीमे शार्ड से सीमित होता है।

रिलीज़ से पहले किसी उम्मीदवार को सत्यापित करते समय पैकेज प्रोफ़ाइल मैन्युअल रूप से चलाएँ:

gh workflow run package-acceptance.yml \  --ref main \  -f workflow_ref=main \  -f source=npm \  -f package_spec=openclaw@beta \  -f suite_profile=package \  -f published_upgrade_survivor_baselines="last-stable-4 2026.4.23 2026.5.2 2026.4.15" \  -f published_upgrade_survivor_scenarios=reported-issues \  -f telegram_mode=mock-openai

प्रकाशित विस्तारित-स्थिर कैनरी के लिए, package_spec=openclaw@extended-stable सेट करें। Docker लेन चलने से पहले पैकेज स्वीकृति उस चयनकर्ता को एक सटीक टारबॉल में समाधान करती है।

जब रिलीज़ संबंधी प्रश्न में MCP चैनल, cron/सबएजेंट सफ़ाई, OpenAI वेब खोज या OpenWebUI शामिल हों, तब suite_profile=product का उपयोग करें। suite_profile=full का उपयोग केवल तभी करें जब आपको पूर्ण Docker रिलीज़-पथ कवरेज चाहिए।

रिलीज़ डिफ़ॉल्ट

रिलीज़ उम्मीदवारों के लिए, डिफ़ॉल्ट प्रमाण स्टैक है:

1. स्रोत-स्तरीय प्रतिगमन के लिए pnpm check:changed और pnpm test:changed।
2. पैकेज आर्टिफ़ैक्ट अखंडता के लिए pnpm release:check।
3. इंस्टॉल/अपडेट/पुनः आरंभ/Plugin अनुबंधों के लिए पैकेज स्वीकृति package प्रोफ़ाइल या रिलीज़-जाँच कस्टम पैकेज लेन।
4. OS-विशिष्ट इंस्टॉलर, ऑनबोर्डिंग और प्लेटफ़ॉर्म व्यवहार के लिए क्रॉस-OS रिलीज़ जाँच।
5. लाइव सुइट केवल तभी, जब परिवर्तित सतह प्रोवाइडर या होस्टेड-सेवा व्यवहार को प्रभावित करती हो।

अनुरक्षक मशीनों पर, व्यापक गेट और Docker/पैकेज उत्पाद प्रमाण स्थानीय प्रमाण स्पष्ट रूप से न किए जाने पर Testbox में चलने चाहिए।

लेगेसी संगतता

संगतता में ढील सीमित और समयबद्ध है:

• 2026.4.25-beta.* सहित 2026.4.25 तक के पैकेज, पैकेज स्वीकृति में पहले से भेजे गए पैकेज मेटाडेटा अंतर सहन कर सकते हैं।
• प्रकाशित 2026.4.26 पैकेज पहले से भेजी गई स्थानीय बिल्ड मेटाडेटा स्टैम्प फ़ाइलों के लिए चेतावनी दे सकता है।
• बाद के पैकेज को आधुनिक अनुबंधों को पूरा करना आवश्यक है। वही अंतर चेतावनी देने या छोड़ने के बजाय विफल होते हैं।

इन पुराने आकारों के लिए नए स्टार्टअप माइग्रेशन न जोड़ें। डॉक्टर मरम्मत जोड़ें या विस्तृत करें, फिर उसे upgrade-survivor, published-upgrade-survivor या अपडेट कमांड द्वारा पुनः आरंभ का स्वामित्व होने पर update-restart-auth से प्रमाणित करें।

कवरेज जोड़ना

अपडेट या Plugin व्यवहार बदलते समय, सबसे निचली उस परत पर कवरेज जोड़ें जो सही कारण से विफल हो सकती है:

• शुद्ध पाथ या मेटाडेटा लॉजिक: स्रोत के पास यूनिट टेस्ट।
• पैकेज इन्वेंटरी या पैक की गई फ़ाइल का व्यवहार: package-dist-inventory या टारबॉल चेकर टेस्ट।
• CLI इंस्टॉल/अपडेट व्यवहार: Docker लेन अभिकथन या फ़िक्स्चर।
• प्रकाशित-रिलीज़ माइग्रेशन व्यवहार: published-upgrade-survivor परिदृश्य।
• अपडेट के स्वामित्व वाला रीस्टार्ट व्यवहार: update-restart-auth।
• रजिस्ट्री/पैकेज स्रोत व्यवहार: test:docker:plugins फ़िक्स्चर या ClawHub फ़िक्स्चर सर्वर।
• डिपेंडेंसी लेआउट या क्लीनअप व्यवहार: रनटाइम निष्पादन और फ़ाइलसिस्टम सीमा, दोनों की पुष्टि करें। npm डिपेंडेंसियाँ Plugin के प्रबंधित npm प्रोजेक्ट के भीतर होइस्ट की जा सकती हैं, इसलिए टेस्ट से यह सिद्ध होना चाहिए कि उस प्रोजेक्ट को स्कैन/साफ़ किया जाता है, न कि यह मान लिया जाए कि केवल Plugin पैकेज-स्थानीय node_modules ट्री ही मौजूद है।

नए Docker फ़िक्स्चर को डिफ़ॉल्ट रूप से हर्मेटिक रखें। स्थानीय फ़िक्स्चर रजिस्ट्रियों और नकली पैकेजों का उपयोग करें, जब तक कि टेस्ट का उद्देश्य लाइव रजिस्ट्री व्यवहार न हो।

विफलता ट्रायेज

आर्टिफ़ैक्ट की पहचान से शुरू करें:

• पैकेज स्वीकृति resolve_package सारांश: स्रोत, संस्करण, SHA-256 और आर्टिफ़ैक्ट का नाम।
• Docker आर्टिफ़ैक्ट: .artifacts/docker-tests/**/summary.json, failures.json, लेन लॉग और दोबारा चलाने के कमांड।
• अपग्रेड सर्वाइवर सारांश: .artifacts/upgrade-survivor/summary.json, जिसमें बेसलाइन संस्करण, कैंडिडेट संस्करण, परिदृश्य, चरण की अवधियाँ और कॉन्फ़िगरेशन रेसिपी कवरेज शामिल हैं।

पूरे रिलीज़ अंब्रेला को दोबारा चलाने के बजाय, उसी पैकेज आर्टिफ़ैक्ट के साथ ठीक उसी विफल लेन को दोबारा चलाना बेहतर है।