Validazione completa del rilascio

Full Release Validation è il processo generale di rilascio: l'unico punto di ingresso manuale per la verifica preliminare al rilascio. La maggior parte del lavoro avviene nei workflow figli, così un ambiente non riuscito può essere rieseguito senza riavviare l'intero rilascio.

Eseguilo da un riferimento di workflow attendibile, normalmente main, e passa il branch di rilascio, il tag o lo SHA completo del commit come ref:

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

provider accetta anche anthropic o minimax per l'onboarding multipiattaforma e il turno end-to-end dell'agente. I job figli riutilizzabili risolvono l'infrastruttura del workflow chiamato da job.workflow_repository e job.workflow_sha, mentre l'input ref seleziona il candidato sottoposto a test. Ciò mantiene disponibile la logica di convalida attendibile corrente quando si convalida un branch o un tag di rilascio precedente.

Ogni workflow figlio avviato deve segnalare lo stesso SHA del workflow dell'esecuzione padre Full Release Validation. Se main cambia tra gli avvii del padre e dei figli, il processo generale fallisce in modo sicuro anche se il workflow figlio ha esito positivo. Per una verifica immutabile di un commit esatto, usa pnpm ci:full-release --sha <target-sha>. L'helper crea un riferimento temporaneo release-ci/* vincolato all'attuale origin/main attendibile, passa lo SHA di destinazione solo come ref del candidato, riutilizza le evidenze rigorose relative alla destinazione esatta quando disponibili ed elimina il riferimento dopo la convalida. Passa -f reuse_evidence=false per forzare una nuova esecuzione oppure --workflow-sha <trusted-main-sha> per selezionare un commit del workflow precedente ancora raggiungibile dall'attuale origin/main. Il workflow non crea né aggiorna mai autonomamente i riferimenti del repository.

release_profile=stable e release_profile=full eseguono sempre il test prolungato completo live/Docker. Passa run_release_soak=true per includere gli stessi percorsi di test prolungato con il profilo beta. La pubblicazione stabile rifiuta un manifest di convalida privo di questo test prolungato e delle evidenze bloccanti sulle prestazioni del prodotto.

Package Acceptance normalmente crea il tarball candidato dal ref risolto, incluse le esecuzioni con SHA completo avviate tramite pnpm ci:full-release. Dopo una pubblicazione beta, passa release_package_spec=openclaw@YYYY.M.PATCH-beta.N per riutilizzare il pacchetto npm pubblicato nei controlli di rilascio, in Package Acceptance, nelle verifiche multipiattaforma, nel percorso di rilascio Docker e nel test Telegram del pacchetto. Usa package_acceptance_package_spec solo quando Package Acceptance deve intenzionalmente verificare un pacchetto diverso. Il percorso del pacchetto live del Plugin Codex segue lo stesso stato: i valori release_package_spec pubblicati derivano codex_plugin_spec=npm:@openclaw/codex@<version>; le esecuzioni tramite SHA/artefatto preparano extensions/codex dal riferimento selezionato; inoltre, gli operatori possono impostare direttamente codex_plugin_spec per sorgenti del Plugin npm:, npm-pack: o git:. Il percorso concede l'approvazione esplicita all'installazione della CLI Codex richiesta da quel Plugin, quindi esegue il controllo preliminare della CLI Codex e i turni dell'agente OpenAI nella stessa sessione.

Fasi di primo livello

Per rerun_group=all, viene eseguito per primo un job Check for reusable validation evidence: cerca la convalida completa precedente più recente con esito positivo per lo stesso identico SHA di destinazione, profilo di rilascio, impostazione effettiva del test prolungato e input di convalida. Quando tali evidenze esistono, ogni percorso viene ignorato e il verificatore generale ricontrolla l'artefatto padre immutabile, le esecuzioni figlie e i log degli avvii. Si tratta esclusivamente del ripristino di una riesecuzione per lo stesso candidato; non autorizza il riutilizzo tra SHA diversi. Per un candidato modificato, riesegui ogni controllo di pacchetto, artefatto, installazione, Docker o provider interessato dalla modifica. Passa reuse_evidence=false per forzare una nuova esecuzione completa. Il riutilizzo delle evidenze viene eseguito solo da main o da un riferimento canonico release-ci/* vincolato a uno SHA il cui commit del workflow rimane nella discendenza attendibile di main; gli altri riferimenti di workflow eseguono nuovamente i percorsi selezionati.

Sempre per rerun_group=all, un job Verify Docker runtime image assets crea la destinazione Docker runtime-assets con OPENCLAW_EXTENSIONS=diagnostics-otel,codex. Viene eseguito in parallelo con le altre fasi ed è imposto dal verificatore generale; i percorsi non ne attendono più il completamento prima dell'avvio. Un rerun_group più specifico ignora questo controllo preliminare.

Il processo generale avvia sempre le prestazioni del prodotto in modalità solo artefatti. OpenClaw Performance consente la pubblicazione dei report solo per le esecuzioni pianificate o per un avvio manuale che imposta esplicitamente publish_reports=true. La protezione della modalità solo artefatti deve completarsi correttamente, dimostrando che il job di pubblicazione è rimasto ignorato. Le evidenze nuove e riutilizzate registrano controls.performanceReportPublication=artifact-only; il verificatore e il selettore per il riutilizzo rifiutano le evidenze prive della corrispondente verifica normalizzata del workflow figlio delle prestazioni.

Il verificatore carica il manifest canonico come full-release-validation-<run-id>-<run-attempt>. Gli strumenti per le evidenze convalidano l'ID dell'artefatto, il digest, l'esecuzione che lo ha prodotto e il tentativo prima di scaricare esattamente quell'ID artefatto. Impongono un limite allo ZIP scaricato, ne verificano i byte rispetto al digest REST sha256: e trasmettono in streaming l'unica voce delimitata e consentita del manifest senza estrarre l'archivio. Un alias con nome stabile viene mantenuto temporaneamente per i consumer di pubblicazione precedenti. Il verificatore preferisce sempre l'artefatto qualificato per tentativo; durante la transizione, accetta il nome stabile solo per un produttore del manifest v2 al tentativo 1. Rifiuta tale nome precedente per i tentativi successivi e per il manifest v3.

Per ref=main con rerun_group=all, per i riferimenti release/* e per i riferimenti alpha di Tideclaw, una nuova esecuzione generale sostituisce una precedente con lo stesso riferimento e lo stesso gruppo di riesecuzione. Quando il processo padre viene annullato, il relativo monitor annulla qualsiasi workflow figlio già avviato. Le esecuzioni di convalida per tag e SHA vincolati non si annullano reciprocamente.

Fasi dei controlli di rilascio

OpenClaw Release Checks è il workflow figlio più esteso. Risolve la destinazione una sola volta e prepara un artefatto condiviso release-package-under-test quando ne hanno bisogno le fasi relative ai pacchetti o a Docker.

Segmenti del percorso di rilascio Docker

La fase del percorso di rilascio Docker esegue questi segmenti quando live_suite_filter è vuoto:

Usa docker_lanes=<lane[,lane]> mirato nel workflow live/E2E riutilizzabile quando è fallita una sola corsia Docker. Gli artefatti del rilascio includono, quando disponibili, comandi di riesecuzione per ciascuna corsia con input per il riutilizzo dell'artefatto del pacchetto e dell'immagine.

Profili di rilascio

release_profile controlla principalmente l'ampiezza dei test live/provider all'interno dei controlli di rilascio. Non rimuove la normale CI completa, la prerelease dei Plugin, lo smoke test di installazione, l'accettazione del pacchetto o QA Lab. I profili stable e full eseguono sempre una copertura esaustiva E2E del repository/live e di soak del percorso di rilascio Docker. Il profilo beta può abilitarla con run_release_soak=true. L'accettazione del pacchetto fornisce l'E2E Telegram canonico del pacchetto per ogni candidato completo, quindi il flusso generale non duplica tale poller live.

Aggiunte esclusive di full

Queste suite vengono saltate da stable e incluse da full:

stable include native-live-src-gateway-profiles-anthropic-smoke e native-live-src-gateway-profiles-opencode-go-smoke; full utilizza invece gli shard più ampi dei modelli Anthropic e OpenCode Go. Le riesecuzioni mirate possono comunque utilizzare gli handle aggregati native-live-src-gateway-profiles-anthropic o native-live-src-gateway-profiles-opencode-go.

Riesecuzioni mirate

Utilizza rerun_group per evitare di ripetere ambienti di rilascio non correlati:

Utilizza live_suite_filter con rerun_group=live-e2e quando una suite live non riesce. Gli ID di filtro validi sono definiti nel workflow live/E2E riutilizzabile, inclusi 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 e live-codex-harness-docker.

L'handle live-gateway-advisory-docker è un handle di riesecuzione aggregato per i suoi tre shard di provider, quindi continua a distribuire l'esecuzione a tutti i job consultivi del Gateway Docker.

Utilizza cross_os_suite_filter con rerun_group=cross-os quando una corsia multipiattaforma non riesce. Il filtro accetta un ID del sistema operativo, un ID della suite o una coppia sistema operativo/suite, ad esempio windows/packaged-upgrade, windows o packaged-fresh. I riepiloghi multipiattaforma includono le tempistiche per fase per le corsie di aggiornamento con pacchetto e i comandi di lunga durata stampano righe di Heartbeat, in modo che un aggiornamento bloccato sia visibile prima del timeout del job.

Gli errori dei controlli di rilascio QA bloccano la normale convalida del rilascio. Anche il controllo della copertura degli strumenti di runtime QA (divergenza dinamica degli strumenti tra openclaw e codex nel livello standard) blocca il verificatore dei controlli di rilascio, anche se la corsia sottostante di parità del runtime QA è consultiva. Le esecuzioni alpha di Tideclaw possono comunque considerare consultive le corsie dei controlli di rilascio non relative alla sicurezza del pacchetto. Con release_profile=beta, le suite di provider live di Run repo/live E2E validation sono consultive: le distribuzioni dei modelli di terze parti cambiano indipendentemente da un rilascio, quindi beta presenta i relativi errori come avvisi, mentre i profili stable e full continuano a considerarli bloccanti. Quando live_suite_filter richiede esplicitamente una corsia QA live soggetta ad abilitazione, come Discord, WhatsApp o Slack, deve essere abilitata la variabile del repository OPENCLAW_RELEASE_QA_*_LIVE_CI_ENABLED corrispondente; in caso contrario, l'acquisizione dell'input non riesce anziché saltare silenziosamente la corsia. Riesegui rerun_group=qa, qa-parity o qa-live quando sono necessarie evidenze QA aggiornate.

Evidenze da conservare

Conserva il riepilogo Full Release Validation come indice a livello di rilascio. Contiene collegamenti agli ID delle esecuzioni figlie e include tabelle dei job più lenti. In caso di errori, esamina prima il workflow figlio, quindi riesegui l'handle corrispondente più specifico tra quelli riportati sopra.

Artefatti utili:

• release-package-under-test da OpenClaw Release Checks
• Artefatti del percorso di rilascio Docker in .artifacts/docker-tests/
• Artefatti package-under-test dell'accettazione del pacchetto e di accettazione Docker
• Artefatti dei controlli di rilascio multipiattaforma per ciascun sistema operativo e suite
• Artefatti di parità QA, parità del runtime, Matrix e Telegram

File dei workflow

• .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