पूर्ण रिलीज़ सत्यापन

Full Release Validation रिलीज़ उत्पाद-सत्यापन का समग्र आवरण है। अधिकांश कार्य चाइल्ड वर्कफ़्लो में होता है, ताकि किसी विफल बॉक्स को पूरी रिलीज़ पुनः आरंभ किए बिना दोबारा चलाया जा सके। Code SHA को फ़्रीज़ करने से पहले रिलीज़ तैयारी चलाएँ; यदि बैकग्राउंड बॉट ने Control UI लोकेल आउटपुट अभी तक लैंड नहीं किया है, तो यह उसे रीफ़्रेश करती है, फिर रिलीज़ CI में प्रयुक्त उसी सख़्त शून्य-फ़ॉलबैक जाँच को लागू करती है।

चेंजलॉग-पूर्व उत्पाद-पूर्ण कमिट को Code SHA के रूप में फ़्रीज़ करें, फिर चलाएँ:

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

provider क्रॉस-OS ऑनबोर्डिंग और एंड-टू-एंड एजेंट टर्न के लिए anthropic या minimax भी स्वीकार करता है। हेल्पर अल्फ़ा/बीटा पैकेज संस्करणों से beta प्रोफ़ाइल और अन्यथा stable का अनुमान लगाता है। वैकल्पिक वर्कफ़्लो इनपुट -f key=value के साथ पास करें; व्यापक एडवाइज़री स्वीप के लिए ही -f release_profile=full का उपयोग करें।

हेल्पर एक विश्वसनीय origin/main वर्कफ़्लो SHA पर पिन किया हुआ अस्थायी release-ci/* रेफ़ बनाता है, लक्ष्य SHA को केवल उम्मीदवार ref के रूप में पास करता है, और सत्यापन के बाद अस्थायी रेफ़ हटा देता है। डिस्पैच किए गए प्रत्येक चाइल्ड को उसी वर्कफ़्लो SHA की रिपोर्ट करनी होगी। नया रन बाध्य करने के लिए -f reuse_evidence=false या वर्तमान origin/main से अब भी पहुँच योग्य पुराना वर्कफ़्लो कमिट चुनने के लिए --workflow-sha <trusted-main-sha> पास करें। वर्कफ़्लो स्वयं कभी रिपॉज़िटरी रेफ़ नहीं बनाता या अपडेट करता।

एक्सटेंडेड-स्टेबल अपवाद

एक्सटेंडेड-स्टेबल प्रकाशन के लिए ऐसा रन आवश्यक है, जिसमें वर्कफ़्लो और लक्ष्य दोनों कैनोनिकल ब्रांच हों:

gh workflow run full-release-validation.yml \  --ref extended-stable/YYYY.M.33 \  -f ref=extended-stable/YYYY.M.33 \  -f release_profile=stable

pnpm ci:full-release या release-ci/* का उपयोग न करें। प्रकाशन रन की ब्रांच, हेड/लक्ष्य SHA, मैनिफ़ेस्ट workflowRef, ID और प्रयास को कैनोनिकल ब्रांच तथा रिलीज़ कमिट से बाँधता है।

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

नियमित रिलीज़ के लिए, Code SHA के हरा होने पर केवल CHANGELOG.md जनरेट और कमिट करें। यह नया कमिट Release SHA है। Release SHA के लिए वही हेल्पर चलाएँ। उत्पाद साक्ष्य का पुनः उपयोग केवल तभी होता है, जब GitHub सिद्ध करे कि Release SHA, Code SHA से व्युत्पन्न है और बदले हुए पथों का पूरा सेट ठीक CHANGELOG.md है; npm प्रीफ़्लाइट और पैकेज/इंस्टॉल स्वीकृति फिर भी Release SHA पर चलते हैं।

release_profile=stable और release_profile=full हमेशा संपूर्ण लाइव/Docker सोक चलाते हैं। beta प्रोफ़ाइल के साथ वही सोक लेन शामिल करने के लिए run_release_soak=true पास करें। इस सोक और अवरोधक उत्पाद-प्रदर्शन साक्ष्य के बिना सत्यापन मैनिफ़ेस्ट को स्टेबल प्रकाशन अस्वीकार करता है।

Package Acceptance सामान्यतः रिज़ॉल्व किए गए ref से उम्मीदवार टारबॉल बनाता है, जिसमें pnpm ci:full-release के साथ डिस्पैच किए गए पूर्ण-SHA रन भी शामिल हैं। बीटा प्रकाशन के बाद, रिलीज़ जाँचों, Package Acceptance, क्रॉस-OS, रिलीज़-पथ Docker और पैकेज Telegram में प्रकाशित npm पैकेज का पुनः उपयोग करने के लिए release_package_spec=openclaw@YYYY.M.PATCH-beta.N पास करें। package_acceptance_package_spec का उपयोग केवल तभी करें, जब Package Acceptance को जानबूझकर किसी भिन्न पैकेज को सिद्ध करना हो। Codex Plugin की लाइव पैकेज लेन भी इसी स्थिति का अनुसरण करती है: प्रकाशित release_package_spec मान codex_plugin_spec=npm:@openclaw/codex@<version> व्युत्पन्न करते हैं; SHA/आर्टिफ़ैक्ट रन चयनित रेफ़ से extensions/codex पैक करते हैं; और ऑपरेटर npm:, npm-pack: या git: Plugin स्रोतों के लिए सीधे codex_plugin_spec सेट कर सकते हैं। लेन उस Plugin के लिए आवश्यक स्पष्ट Codex CLI इंस्टॉल अनुमोदन प्रदान करती है, फिर Codex CLI प्रीफ़्लाइट और उसी सेशन में OpenAI एजेंट टर्न चलाती है। उसका अंतिम शून्य-पुनःप्रयास, मध्यम-चिंतन टर्न Codex final को छोड़े रखते हुए दृश्यमान प्रगति भेजता है, रैंडमाइज़ किए गए वर्कस्पेस इनपुट पढ़ता है, उनका सटीक आर्टिफ़ैक्ट लिखता है और स्पष्ट पूर्णता संदेश भेजता है। यह v2026.7.1 की उस रिग्रेशन को पकड़ता है, जिसमें सामान्य प्रगति संदेश भेजने पर टर्न समाप्त हो जाता था।

शीर्ष-स्तरीय चरण

rerun_group=all के लिए, पहले एक Check for reusable validation evidence जॉब चलता है। यह समान रिलीज़ प्रोफ़ाइल, प्रभावी सोक सेटिंग और सत्यापन इनपुट वाला सबसे नया पूर्व हरा पूर्ण सत्यापन खोजता है। सटीक-लक्ष्य पुनःरन exact-target-full-validation-v1 का उपयोग करते हैं। ऐसा वंशज जिसका पूरा डेल्टा ठीक CHANGELOG.md है, changelog-only-release-v1 का उपयोग करता है; प्रत्येक उत्पाद लेन छोड़ दी जाती है और सत्यापक स्वतंत्र रूप से GitHub कमिट तुलना, अपरिवर्तनीय पैरेंट आर्टिफ़ैक्ट, चाइल्ड रन और डिस्पैच लॉग की दोबारा जाँच करता है। किसी अन्य लक्ष्य परिवर्तन के लिए नया Code SHA सत्यापन आवश्यक है। नया पूर्ण रन बाध्य करने के लिए reuse_evidence=false पास करें। साक्ष्य का पुनः उपयोग केवल main या कैनोनिकल SHA-पिन किए गए release-ci/* रेफ़ से चलता है, जिसका वर्कफ़्लो कमिट विश्वसनीय main वंशावली पर बना रहता है; अन्य वर्कफ़्लो रेफ़ चयनित लेन को नए सिरे से चलाते हैं।

नया पैकेज-संबंधी सत्यापन Plugin Prerelease और OpenClaw Release Checks को डिस्पैच करने से पहले एक अपरिवर्तनीय टारबॉल और एक Docker इमेज आर्टिफ़ैक्ट तैयार करता है। दोनों चाइल्ड उपयोग से पहले समान पैकेज SHA, आर्टिफ़ैक्ट ID, सेवा डाइजेस्ट, उत्पादक रन प्रयास और Docker आर्काइव डाइजेस्ट सत्यापित करते हैं। पैकेज-स्वतंत्र बेर Docker परत सामग्री-पते वाले GHCR कैश का उपयोग करती है; उम्मीदवार-विशिष्ट इमेज अपरिवर्तनीय GitHub आर्टिफ़ैक्ट बनी रहती हैं। स्पष्ट प्रकाशित पैकेज विनिर्देश वाले केंद्रित रन इसके बजाय मौजूदा पैकेज पथ बनाए रखते हैं।

साथ ही rerun_group=all के लिए, एक Verify Docker runtime image assets जॉब OPENCLAW_EXTENSIONS=diagnostics-otel,codex के साथ runtime-assets Docker लक्ष्य बनाता है। यह अन्य चरणों के समानांतर चलता है और समग्र सत्यापक द्वारा लागू किया जाता है; लेन अब डिस्पैच करने से पहले इसकी प्रतीक्षा नहीं करतीं। अधिक सीमित rerun_group इस प्रीफ़्लाइट को छोड़ देता है।

समग्र आवरण हमेशा उत्पाद प्रदर्शन को केवल-आर्टिफ़ैक्ट मोड में डिस्पैच करता है। OpenClaw Performance रिपोर्ट प्रकाशन की अनुमति केवल शेड्यूल किए गए रन या ऐसे मैन्युअल डिस्पैच के लिए देता है जो स्पष्ट रूप से publish_reports=true सेट करता हो। केवल-आर्टिफ़ैक्ट गार्ड को सफलतापूर्वक पूरा होना होगा, जिससे सिद्ध हो कि प्रकाशक जॉब छोड़ा हुआ रहा। नए और पुनः प्रयुक्त साक्ष्य controls.performanceReportPublication=artifact-only दर्ज करते हैं; सत्यापक और पुनः उपयोग चयनकर्ता मेल खाते सामान्यीकृत प्रदर्शन-चाइल्ड प्रमाण के बिना साक्ष्य अस्वीकार करते हैं।

सत्यापक कैनॉनिकल मैनिफ़ेस्ट को full-release-validation-<run-id>-<run-attempt> के रूप में अपलोड करता है। साक्ष्य टूलिंग उस सटीक आर्टिफ़ैक्ट ID को डाउनलोड करने से पहले उसके आर्टिफ़ैक्ट ID, डाइजेस्ट, निर्माता रन और प्रयास को सत्यापित करती है। यह डाउनलोड किए गए ZIP के आकार को सीमित करती है, REST sha256: डाइजेस्ट के विरुद्ध उसके बाइट्स सत्यापित करती है, और आर्काइव को निकाले बिना एकमात्र अनुमत सीमित मैनिफ़ेस्ट प्रविष्टि को स्ट्रीम करती है। पुराने प्रकाशन उपभोक्ताओं के लिए स्थिर-नाम उपनाम अस्थायी रूप से बना रहता है। सत्यापक हमेशा प्रयास-योग्य आर्टिफ़ैक्ट को प्राथमिकता देता है; संक्रमण के रूप में, यह स्थिर नाम केवल प्रयास-1 मैनिफ़ेस्ट v2 निर्माता के लिए स्वीकार करता है। यह बाद के प्रयासों और मैनिफ़ेस्ट v3 के लिए उस विरासती नाम को अस्वीकार करता है।

rerun_group=all वाले ref=main के लिए, release/* रेफ़्स के लिए और Tideclaw अल्फ़ा रेफ़्स के लिए, एक नया अम्ब्रेला रन समान रेफ़ और पुनः-रन समूह वाले पुराने रन का स्थान ले लेता है। जब पैरेंट रद्द किया जाता है, तो उसका मॉनिटर उसके द्वारा पहले ही डिस्पैच किए गए किसी भी चाइल्ड वर्कफ़्लो को रद्द कर देता है। टैग और पिन किए गए-SHA सत्यापन रन एक-दूसरे को रद्द नहीं करते।

रिलीज़ जाँच के चरण

OpenClaw Release Checks सबसे बड़ा चाइल्ड वर्कफ़्लो है। यह लक्ष्य को एक बार रिज़ॉल्व करता है और उपलब्ध होने पर अम्ब्रेला के साझा पैकेज आर्टिफ़ैक्ट को सत्यापित करता है। कोई प्रत्यक्ष या केंद्रित डिस्पैच, पैकेज या Docker-संबंधित चरणों को आवश्यकता होने पर अपना release-package-under-test आर्टिफ़ैक्ट तैयार करता है।

Docker रिलीज़-पथ खंड

जब live_suite_filter खाली होता है, तब Docker रिलीज़-पथ चरण ये खंड चलाता है:

जब केवल एक Docker लेन विफल हो, तब पुनः उपयोग योग्य लाइव/E2E वर्कफ़्लो पर लक्षित docker_lanes=<lane[,lane]> का उपयोग करें। उपलब्ध होने पर, रिलीज़ आर्टिफ़ैक्ट में पैकेज आर्टिफ़ैक्ट और इमेज पुनः उपयोग इनपुट वाली प्रति-लेन पुनः चलाने की कमांड शामिल होती हैं।

रिलीज़ प्रोफ़ाइल

release_profile मुख्यतः रिलीज़ जाँचों के भीतर लाइव/प्रदाता विस्तार को नियंत्रित करता है। यह सामान्य पूर्ण CI, Plugin प्रीरिलीज़, इंस्टॉल स्मोक, पैकेज स्वीकृति या QA Lab को नहीं हटाता। स्थिर और पूर्ण प्रोफ़ाइल हमेशा व्यापक रिपॉज़िटरी/लाइव E2E और Docker रिलीज़-पथ सोक कवरेज चलाती हैं। बीटा प्रोफ़ाइल run_release_soak=true के साथ इसे चुन सकती है। पैकेज स्वीकृति प्रत्येक पूर्ण उम्मीदवार के लिए मानक पैकेज Telegram E2E प्रदान करती है, इसलिए समग्र वर्कफ़्लो उस लाइव पोलर को दोहराता नहीं है।

केवल पूर्ण प्रोफ़ाइल के अतिरिक्त भाग

इन सुइट को stable द्वारा छोड़ा जाता है और full द्वारा शामिल किया जाता है:

stable में native-live-src-gateway-profiles-anthropic-smoke और native-live-src-gateway-profiles-opencode-go-smoke शामिल हैं; इसके बजाय full अधिक व्यापक Anthropic और OpenCode Go मॉडल शार्ड का उपयोग करता है। केंद्रित पुनः संचालन अब भी समग्र native-live-src-gateway-profiles-anthropic या native-live-src-gateway-profiles-opencode-go हैंडल का उपयोग कर सकते हैं।

केंद्रित पुनः संचालन

असंबंधित रिलीज़ बॉक्स को दोहराने से बचने के लिए rerun_group का उपयोग करें:

जब एक लाइव सुइट विफल हो, तब rerun_group=live-e2e के साथ live_suite_filter का उपयोग करें। मान्य फ़िल्टर आईडी पुनः उपयोग योग्य लाइव/E2E वर्कफ़्लो में परिभाषित हैं, जिनमें docker-live-models, live-gateway-docker, live-gateway-anthropic-docker, live-gateway-google-docker, live-gateway-minimax-docker, live-gateway-advisory-docker, live-cli-backend-docker, live-acp-bind-docker, और live-codex-harness-docker शामिल हैं।

केंद्रित QA ट्रांसपोर्ट पुनः संचालन के लिए, rerun_group=qa-live सेट करें और मानक चयनकर्ता qa-live-matrix, qa-live-telegram, qa-live-discord, qa-live-whatsapp, या qa-live-slack का उपयोग करें।

live-gateway-advisory-docker हैंडल अपने तीन प्रदाता शार्ड के लिए एक समग्र पुनः संचालन हैंडल है, इसलिए यह अब भी सभी परामर्शी Docker Gateway जॉब में फैलता है।

जब एक क्रॉस-OS लेन विफल हो, तब rerun_group=cross-os के साथ cross_os_suite_filter का उपयोग करें। फ़िल्टर एक OS आईडी, सुइट आईडी, या OS/सुइट युग्म स्वीकार करता है, उदाहरण के लिए windows/packaged-upgrade, windows, या packaged-fresh। क्रॉस-OS सारांश में पैकेज किए गए अपग्रेड लेन के लिए प्रति-चरण समय शामिल होता है, और लंबे समय तक चलने वाली कमांड Heartbeat पंक्तियाँ प्रिंट करती हैं, ताकि जॉब टाइमआउट से पहले अटका हुआ अपडेट दिखाई दे।

QA रिलीज़-जाँच विफलताएँ केवल चयनित Matrix, Telegram और QA रनटाइम टूल कवरेज लेन के लिए सामान्य रिलीज़ सत्यापन को अवरुद्ध करती हैं। QA समतुल्यता, रनटाइम समतुल्यता और गेटेड Discord, WhatsApp तथा Slack लाइव लेन परामर्शी हैं और रिलीज़ सत्यापक को अवरुद्ध किए बिना स्थिति आर्टिफ़ैक्ट प्रकाशित करती हैं। Tideclaw अल्फ़ा संचालन अब भी गैर-पैकेज-सुरक्षा रिलीज़-जाँच लेन को परामर्शी मान सकते हैं। release_profile=beta के साथ, Run repo/live E2E validation लाइव-प्रदाता सुइट परामर्शी हैं: तृतीय-पक्ष मॉडल परिनियोजन किसी रिलीज़ के अंतर्गत बदलते रहते हैं, इसलिए बीटा उनकी विफलताओं को चेतावनियों के रूप में दिखाता है, जबकि स्थिर और पूर्ण प्रोफ़ाइल उन्हें अवरोधक बनाए रखती हैं। जब live_suite_filter स्पष्ट रूप से Discord, WhatsApp या Slack जैसी गेटेड QA लाइव लेन का अनुरोध करता है, तब संबंधित OPENCLAW_RELEASE_QA_*_LIVE_CI_ENABLED रिपॉज़िटरी चर सक्षम होना चाहिए; अन्यथा लेन को चुपचाप छोड़ने के बजाय इनपुट कैप्चर विफल हो जाता है। जब आपको नए QA प्रमाण की आवश्यकता हो, तब rerun_group=qa, qa-parity, या qa-live को पुनः चलाएँ।

बनाए रखने योग्य प्रमाण

रिलीज़-स्तरीय अनुक्रमणिका के रूप में Full Release Validation सारांश बनाए रखें। यह चाइल्ड रन आईडी से लिंक करता है और इसमें सबसे धीमे जॉब की तालिकाएँ शामिल होती हैं। विफलताओं के लिए, पहले चाइल्ड वर्कफ़्लो का निरीक्षण करें, फिर ऊपर दिए गए सबसे छोटे मेल खाते हैंडल को पुनः चलाएँ।

नियमित रिलीज़ के लिए, Code SHA और Release SHA दोनों, पुनः उपयोग नीति और बदले गए पथों का सेट, सफल Code SHA पैरेंट रन तथा हल्का Release SHA पैरेंट रन दर्ज करें। विस्तारित-स्थिर के लिए, मानक शाखा, सटीक रिलीज़ SHA, नया पैरेंट रन आईडी और प्रयास, वर्कफ़्लो रेफ़, प्रत्येक चाइल्ड रन, और कोई भी स्थिर-लक्ष्य संगतता सुधार या जानबूझकर किया गया अपवर्जन दर्ज करें।

उपयोगी आर्टिफ़ैक्ट:

• OpenClaw Release Checks से release-package-under-test
• .artifacts/docker-tests/ के अंतर्गत Docker रिलीज़-पथ आर्टिफ़ैक्ट
• पैकेज स्वीकृति package-under-test और Docker स्वीकृति आर्टिफ़ैक्ट
• प्रत्येक OS और सुइट के लिए क्रॉस-OS रिलीज़-जाँच आर्टिफ़ैक्ट
• QA समतुल्यता, रनटाइम समतुल्यता, और चयनित Matrix, Telegram, Discord, WhatsApp, या Slack आर्टिफ़ैक्ट

वर्कफ़्लो फ़ाइलें

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