Validation complète de la version

Full Release Validation est l’ombrelle de publication. C’est le point d’entrée manuel unique pour la preuve de prépublication, mais la majeure partie du travail se fait dans des workflows enfants afin qu’une boîte en échec puisse être relancée sans redémarrer toute la publication. Exécutez-le depuis une référence de workflow de confiance, normalement main, et transmettez la branche de publication, le tag ou le SHA complet du commit comme ref :

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

Les workflows enfants utilisent la référence de workflow de confiance pour le harnais et l’entrée ref pour le candidat testé. Cela garde la nouvelle logique de validation disponible lors de la validation d’une ancienne branche de publication ou d’un ancien tag. Par défaut, release_profile=stable exécute les voies bloquantes pour la publication et ignore le soak exhaustif live/Docker. Passez run_release_soak=true pour inclure les voies de soak lors d’une exécution stable. release_profile=full active toujours les voies de soak afin que le large profil consultatif ne perde jamais de couverture silencieusement. Package Acceptance construit normalement le tarball candidat depuis le ref résolu, y compris les exécutions avec SHA complet déclenchées avec pnpm ci:full-release. Après publication, passez package_acceptance_package_spec=openclaw@YYYY.M.D (ou openclaw@beta/openclaw@latest) pour exécuter à la place la même matrice package/mise à jour contre le package npm publié.

Étapes de premier niveau

Étape	Détails
Résolution de la cible	Tâche : `Resolve target ref` Workflow enfant : aucun Prouve : résout la branche de publication, le tag ou le SHA complet du commit et enregistre les entrées sélectionnées. Relance : relancez l’ombrelle si cela échoue.
Vitest et CI normale	Tâche : `Run normal full CI` Workflow enfant : `CI` Prouve : graphe CI complet manuel contre la référence cible, y compris les voies Linux Node, les segments Plugin groupés, les contrats de canaux, la compatibilité Node 22, `check`, `check-additional`, le smoke de build, les vérifications de documentation, les Skills Python, Windows, macOS, l’i18n de l’interface de contrôle et Android via l’ombrelle. Relance : `rerun_group=ci`.
Prépublication Plugin	Tâche : `Run plugin prerelease validation` Workflow enfant : `Plugin Prerelease` Prouve : vérifications statiques Plugin propres à la publication, couverture Plugin agentique, segments de lot d’extensions complets et voies Docker de prépublication Plugin. Relance : `rerun_group=plugin-prerelease`.
Vérifications de publication	Tâche : `Run release/live/Docker/QA validation` Workflow enfant : `OpenClaw Release Checks` Prouve : smoke d’installation, vérifications de package multi-OS, Package Acceptance, parité QA Lab, Matrix live et Telegram live. Avec `run_release_soak=true` ou `release_profile=full`, exécute également les suites live/E2E exhaustives et les morceaux du chemin de publication Docker. Relance : `rerun_group=release-checks` ou un handle release-checks plus restreint.
Artefact de package	Tâche : `Prepare release package artifact` Workflow enfant : aucun Prouve : crée le tarball parent `release-package-under-test` assez tôt pour les vérifications orientées package qui n’ont pas besoin d’attendre `OpenClaw Release Checks`. Relance : relancez l’ombrelle ou fournissez `npm_telegram_package_spec` pour `rerun_group=npm-telegram`.
Package Telegram	Tâche : `Run package Telegram E2E` Workflow enfant : `NPM Telegram Beta E2E` Prouve : preuve du package Telegram adossée à l’artefact parent pour `rerun_group=all` avec `release_profile=full`, ou preuve Telegram du package publié quand `npm_telegram_package_spec` est défini. Relance : `rerun_group=npm-telegram` avec `npm_telegram_package_spec`.
Vérificateur d’ombrelle	Tâche : `Verify full validation` Workflow enfant : aucun Prouve : revérifie les conclusions enregistrées des exécutions enfants et ajoute les tableaux des tâches les plus lentes depuis les workflows enfants. Relance : relancez uniquement cette tâche après avoir relancé un enfant en échec jusqu’au vert.

Pour ref=main et rerun_group=all, une ombrelle plus récente remplace une ancienne. Quand le parent est annulé, son moniteur annule tout workflow enfant qu’il a déjà déclenché. Les exécutions de validation de branche de publication et de tag ne s’annulent pas entre elles par défaut.

Étapes des vérifications de publication

OpenClaw Release Checks est le plus grand workflow enfant. Il résout la cible une fois et prépare un artefact partagé release-package-under-test quand les étapes orientées package ou Docker en ont besoin.

Étape	Détails
Cible de release	Job : `Resolve target ref` Workflow sous-jacent : aucun Tests : ref sélectionnée, SHA attendu facultatif, profil, groupe de relance et filtre de suite live ciblée. Relance : `rerun_group=release-checks`.
Artefact de package	Job : `Prepare release package artifact` Workflow sous-jacent : aucun Tests : package ou résout une archive tarball candidate et téléverse `release-package-under-test` pour les vérifications aval orientées package. Relance : le package, le groupe cross-OS ou live/E2E affecté.
Smoke d’installation	Job : `Run install smoke` Workflow sous-jacent : `Install Smoke` Tests : chemin d’installation complet avec réutilisation de l’image smoke Dockerfile racine, installation du package QR, smokes Docker racine et Gateway, tests Docker de l’installateur, smoke de fournisseur d’images pour installation globale Bun et E2E rapide d’installation/désinstallation de Plugin groupé. Relance : `rerun_group=install-smoke`.
Cross-OS	Job : `cross_os_release_checks` Workflow sous-jacent : `OpenClaw Cross-OS Release Checks (Reusable)` Tests : voies d’installation fraîche et de mise à niveau sur Linux, Windows et macOS pour le fournisseur et le mode sélectionnés, avec l’archive tarball candidate et un package de référence. Relance : `rerun_group=cross-os`.
E2E repo et live	Job : `Run repo/live E2E validation` Workflow sous-jacent : `OpenClaw Live And E2E Checks (Reusable)` Tests : E2E du dépôt, cache live, streaming websocket OpenAI, fragments de fournisseur live natif et de Plugin, et harnais live adossés à Docker pour modèle/backend/Gateway sélectionnés par `release_profile`. Exécutions : `run_release_soak=true`, `release_profile=full` ou `rerun_group=live-e2e` ciblé. Relance : `rerun_group=live-e2e`, éventuellement avec `live_suite_filter`.
Chemin de release Docker	Job : `Run Docker release-path validation` Workflow sous-jacent : `OpenClaw Live And E2E Checks (Reusable)` Tests : morceaux Docker de chemin de release avec l’artefact de package partagé. Exécutions : `run_release_soak=true`, `release_profile=full` ou `rerun_group=live-e2e` ciblé. Relance : `rerun_group=live-e2e`.
Acceptation de package	Job : `Run package acceptance` Workflow sous-jacent : `Package Acceptance` Tests : fixtures de package Plugin hors ligne, mise à jour de Plugin, acceptation de package Telegram avec OpenAI simulé et vérifications de survivance après mise à niveau publiée avec la même archive tarball. Les vérifications de release bloquantes utilisent la référence publiée la plus récente par défaut ; les vérifications de soak s’étendent à chaque release npm stable à partir de `2026.4.23`, ainsi qu’aux fixtures de problèmes signalés. Relance : `rerun_group=package`.
Parité QA	Job : `Run QA Lab parity lane` et `Run QA Lab parity report` Workflow sous-jacent : jobs directs Tests : packs de parité agentique candidat et de référence, puis le rapport de parité. Relance : `rerun_group=qa-parity` ou `rerun_group=qa`.
Matrix live QA	Job : `Run QA Lab live Matrix lane` Workflow sous-jacent : job direct Tests : profil QA Matrix live rapide dans l’environnement `qa-live-shared`. Relance : `rerun_group=qa-live` ou `rerun_group=qa`.
Telegram live QA	Job : `Run QA Lab live Telegram lane` Workflow sous-jacent : job direct Tests : QA Telegram live avec baux d’identifiants Convex CI. Relance : `rerun_group=qa-live` ou `rerun_group=qa`.
Vérificateur de release	Job : `Verify release checks` Workflow sous-jacent : aucun Tests : jobs de vérification de release requis pour le groupe de relance sélectionné. Relance : relancer après la réussite des jobs enfants ciblés.

Morceaux du chemin de release Docker

L’étape du chemin de release Docker exécute ces morceaux lorsque live_suite_filter est vide :

Morceau	Couverture
`core`	Voies smoke du chemin de release Docker core.
`package-update-openai`	Comportement d’installation et de mise à jour du package OpenAI.
`package-update-anthropic`	Comportement d’installation et de mise à jour du package Anthropic.
`package-update-core`	Comportement de package et de mise à jour indépendant du fournisseur.
`plugins-runtime-plugins`	Voies d’exécution Plugin qui exercent le comportement des Plugins.
`plugins-runtime-services`	Voies d’exécution Plugin adossées à un service ; inclut OpenWebUI lorsque demandé.
`plugins-runtime-install-a` through `plugins-runtime-install-h`	Lots d’installation/exécution de Plugins répartis pour la validation de release parallèle.

Utilisez docker_lanes=<lane[,lane]> ciblé sur le workflow live/E2E réutilisable lorsque une seule voie Docker a échoué. Les artefacts de release incluent des commandes de relance par voie avec les entrées d’artefact de package et de réutilisation d’image lorsqu’elles sont disponibles.

Profils de release

release_profile contrôle principalement l’étendue live/fournisseur dans les vérifications de release. Il ne supprime pas la CI complète normale, la prérelease de Plugin, le smoke d’installation, l’acceptation de package ni le QA Lab. Pour stable, les E2E repo/live exhaustifs et les morceaux du chemin de release Docker relèvent de la couverture de soak et s’exécutent lorsque run_release_soak=true. full force aussi la couverture de soak et fait également exécuter par le workflow ombrelle l’E2E Telegram de package avec l’artefact de package de release parent lorsque rerun_group=all, afin qu’un candidat complet avant publication n’ignore pas silencieusement cette voie de package Telegram.

Profil	Usage prévu	Couverture live/fournisseur incluse
`minimum`	Smoke le plus rapide critique pour la release.	Chemin live OpenAI/core, modèles live Docker pour OpenAI, core Gateway natif, profil Gateway OpenAI natif, Plugin OpenAI natif et Gateway live Docker OpenAI.
`stable`	Profil d’approbation de release par défaut.	`minimum` plus smoke Anthropic, Google, MiniMax, backend, harnais de test live natif, backend CLI live Docker, liaison ACP Docker, harnais Codex Docker et un fragment smoke OpenCode Go.
`full`	Balayage consultatif étendu.	`stable` plus fournisseurs consultatifs, fragments live de Plugins et fragments live média.

Ajouts propres à full

Ces suites sont ignorées par stable et incluses par full :

Zone	Couverture propre à full
Modèles live Docker	OpenCode Go, OpenRouter, xAI, Z.ai et Fireworks.
Gateway live Docker	Fournisseurs consultatifs répartis en fragments DeepSeek/Fireworks, OpenCode Go/OpenRouter et xAI/Z.ai.
Profils de fournisseur Gateway natifs	Fragments Anthropic Opus et Sonnet/Haiku complets, Fireworks, DeepSeek, fragments de modèles OpenCode Go complets, OpenRouter, xAI et Z.ai.
Fragments live Plugin natifs	Plugins A-K, L-N, O-Z autres, Moonshot et xAI.
Fragments live média natifs	Audio, musique Google, musique MiniMax et groupes vidéo A-D.

stable inclut native-live-src-gateway-profiles-anthropic-smoke et native-live-src-gateway-profiles-opencode-go-smoke ; full utilise à la place les fragments de modèles Anthropic et OpenCode Go plus étendus. Les relances ciblées peuvent toujours utiliser les identifiants agrégés native-live-src-gateway-profiles-anthropic ou native-live-src-gateway-profiles-opencode-go.

Relances ciblées

Utilisez rerun_group pour éviter de répéter des boîtes de release sans rapport :

Identifiant	Portée
`all`	Toutes les étapes de Full Release Validation.
`ci`	Enfant CI complet manuel uniquement.
`plugin-prerelease`	Enfant Plugin Prerelease uniquement.
`release-checks`	Toutes les étapes d’OpenClaw Release Checks.
`install-smoke`	Install Smoke jusqu’aux vérifications de publication.
`cross-os`	Vérifications de publication inter-OS.
`live-e2e`	Validation E2E dépôt/live et chemin de publication Docker.
`package`	Package Acceptance.
`qa`	Parité QA plus voies live QA.
`qa-parity`	Voies de parité QA et rapport uniquement.
`qa-live`	Matrice live QA et Telegram uniquement.
`npm-telegram`	E2E Telegram du package publié ; nécessite `npm_telegram_package_spec`.

Utilisez live_suite_filter avec rerun_group=live-e2e lorsqu’une suite live a échoué. Les identifiants de filtre valides sont définis dans le workflow live/E2E réutilisable, notamment 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 et live-codex-harness-docker. L’identifiant live-gateway-advisory-docker est un identifiant de relance agrégé pour ses trois fragments de fournisseur ; il se déploie donc toujours vers toutes les tâches Gateway Docker d’avis. Utilisez cross_os_suite_filter avec rerun_group=cross-os lorsqu’une voie inter-OS a échoué. Le filtre accepte un identifiant d’OS, un identifiant de suite ou une paire OS/suite, par exemple windows/packaged-upgrade, windows ou packaged-fresh. Les résumés inter-OS incluent les minutages par phase pour les voies de mise à niveau empaquetée, et les commandes longues affichent des lignes de Heartbeat afin qu’une mise à jour Windows bloquée soit visible avant le délai d’expiration de la tâche. Les voies QA des vérifications de publication sont consultatives. Un échec limité à la QA est signalé comme un avertissement et ne bloque pas le vérificateur de publication ; relancez rerun_group=qa, qa-parity ou qa-live lorsque vous avez besoin de preuves QA récentes.

Preuves à conserver

Conservez le résumé Full Release Validation comme index de niveau publication. Il lie les identifiants des exécutions enfants et inclut les tableaux des tâches les plus lentes. En cas d’échec, inspectez d’abord le workflow enfant, puis relancez le plus petit identifiant correspondant ci-dessus. Artefacts utiles :

release-package-under-test depuis le parent Full Release Validation et OpenClaw Release Checks
Artefacts du chemin de publication Docker sous .artifacts/docker-tests/
package-under-test de Package Acceptance et artefacts d’acceptation Docker
Artefacts de vérification de publication inter-OS pour chaque OS et suite
Artefacts de parité QA, Matrix et Telegram

Fichiers de 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/openclaw-cross-os-release-checks-reusable.yml
.github/workflows/package-acceptance.yml

CLI commands

RPC and API

Codex harness

Templates

Technical reference

Concept internals

Project

Release and CI

Validation complète de la version

Étapes de premier niveau

Étapes des vérifications de publication

Morceaux du chemin de release Docker

Profils de release

Ajouts propres à full

Relances ciblées

Preuves à conserver

Fichiers de workflow

CLI commands

RPC and API

Codex harness

Templates

Technical reference

Concept internals

Project

Release and CI

Documentation Index

​Étapes de premier niveau

​Étapes des vérifications de publication

​Morceaux du chemin de release Docker

​Profils de release

​Ajouts propres à full

​Relances ciblées

​Preuves à conserver

​Fichiers de workflow

Étapes de premier niveau

Étapes des vérifications de publication

Morceaux du chemin de release Docker

Profils de release

Ajouts propres à full

Relances ciblées

Preuves à conserver

Fichiers de workflow