Validation complète de la version publiée

Full Release Validation est le processus global de validation de version : le point d’entrée manuel unique pour les preuves avant publication. La majeure partie du travail s’effectue dans des workflows enfants afin qu’un environnement en échec puisse être réexécuté sans relancer toute la publication.

Exécutez-le depuis une référence de workflow approuvée, généralement main, et transmettez la branche de publication, le tag ou le SHA complet du commit via 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 accepte également anthropic ou minimax pour l’intégration multiplateforme et le tour d’agent de bout en bout. Les tâches enfants réutilisables résolvent le harnais du workflow appelé à partir de job.workflow_repository et job.workflow_sha, tandis que l’entrée ref sélectionne le candidat testé. Cela permet de conserver la logique actuelle de validation approuvée lors de la validation d’une branche de publication ou d’un tag plus ancien.

Chaque enfant lancé doit signaler le même SHA de workflow que l’exécution parente Full Release Validation. Si main évolue entre les lancements du parent et des enfants, le processus global échoue de manière sécurisée, même si l’enfant lui-même réussit. Pour une preuve immuable portant sur un commit exact, utilisez pnpm ci:full-release --sha <target-sha>. L’utilitaire crée une référence temporaire release-ci/* épinglée sur la version approuvée actuelle de origin/main, transmet le SHA cible uniquement comme ref du candidat, réutilise les preuves strictes correspondant exactement à la cible lorsqu’elles sont disponibles, puis supprime la référence après la validation. Transmettez -f reuse_evidence=false pour forcer une nouvelle exécution ou --workflow-sha <trusted-main-sha> pour sélectionner un commit de workflow plus ancien encore accessible depuis la version actuelle de origin/main. Le workflow ne crée ni ne met à jour lui-même les références du dépôt.

release_profile=stable et release_profile=full exécutent toujours le test prolongé exhaustif en conditions réelles/Docker. Transmettez run_release_soak=true pour inclure les mêmes couloirs de test prolongé avec le profil beta. La publication stable rejette tout manifeste de validation dépourvu de ce test prolongé et de preuves bloquantes sur les performances du produit.

Package Acceptance construit normalement l’archive tar du candidat à partir de la ref résolue, y compris pour les exécutions portant sur un SHA complet lancées avec pnpm ci:full-release. Après une publication bêta, transmettez release_package_spec=openclaw@YYYY.M.PATCH-beta.N afin de réutiliser le paquet npm publié pour les vérifications de publication, Package Acceptance, les tests multiplateformes, le parcours de publication Docker et Telegram avec le paquet. Utilisez package_acceptance_package_spec uniquement lorsque Package Acceptance doit intentionnellement valider un autre paquet. Le couloir du paquet actif du Plugin Codex suit le même état : les valeurs publiées de release_package_spec produisent codex_plugin_spec=npm:@openclaw/codex@<version> ; les exécutions basées sur un SHA ou un artefact empaquettent extensions/codex depuis la référence sélectionnée ; et les opérateurs peuvent définir directement codex_plugin_spec pour des sources de Plugin npm:, npm-pack: ou git:. Le couloir accorde l’autorisation explicite d’installation de la CLI Codex requise par ce Plugin, puis exécute les contrôles préalables de la CLI Codex et les tours d’agent OpenAI dans la même session.

Étapes de premier niveau

Pour rerun_group=all, une tâche Check for reusable validation evidence s’exécute en premier : elle recherche la validation complète réussie antérieure la plus récente pour exactement le même SHA cible, profil de publication, réglage effectif du test prolongé et mêmes entrées de validation. Lorsque de telles preuves existent, chaque couloir est ignoré et le vérificateur global revérifie l’artefact parent immuable, les exécutions enfants et les journaux de lancement. Cela sert uniquement à reprendre une réexécution du même candidat ; cela n’autorise pas la réutilisation entre différents SHA. Pour un candidat modifié, réexécutez chaque contrôle de paquet, d’artefact, d’installation, de Docker ou de fournisseur affecté par cette différence. Transmettez reuse_evidence=false pour forcer une nouvelle exécution complète. La réutilisation des preuves ne s’effectue que depuis main ou une référence canonique release-ci/* épinglée sur un SHA dont le commit de workflow appartient toujours à la lignée approuvée de main ; les autres références de workflow exécutent à nouveau les couloirs sélectionnés.

Également pour rerun_group=all, une tâche Verify Docker runtime image assets construit la cible Docker runtime-assets avec OPENCLAW_EXTENSIONS=diagnostics-otel,codex. Elle s’exécute en parallèle avec les autres étapes et son résultat est imposé par le vérificateur global ; les couloirs n’attendent plus sa fin avant d’être lancés. Un rerun_group plus restreint ignore ce contrôle préalable.

Le processus global lance toujours les performances du produit en mode artefact uniquement. OpenClaw Performance n’autorise la publication des rapports que pour les exécutions planifiées ou un lancement manuel définissant explicitement publish_reports=true. Le contrôle du mode artefact uniquement doit réussir, prouvant que la tâche de publication est restée ignorée. Les preuves nouvelles et réutilisées enregistrent controls.performanceReportPublication=artifact-only ; le vérificateur et le sélecteur de réutilisation rejettent les preuves qui ne contiennent pas la preuve normalisée correspondante de l’enfant chargé des performances.

Le vérificateur téléverse le manifeste canonique sous le nom full-release-validation-<run-id>-<run-attempt>. Les outils de gestion des preuves valident l’identifiant de son artefact, son condensat, l’exécution productrice et la tentative avant de télécharger cet identifiant d’artefact exact. Ils plafonnent la taille du ZIP téléchargé, vérifient ses octets à l’aide du condensat REST sha256: et diffusent en continu la seule entrée de manifeste bornée autorisée sans extraire l’archive. Un alias au nom stable est temporairement conservé pour les anciens consommateurs de publication. Le vérificateur privilégie toujours l’artefact qualifié par la tentative ; pendant la transition, il n’accepte le nom stable que pour un producteur de manifeste v2 à la tentative 1. Il rejette cet ancien nom pour les tentatives ultérieures et pour le manifeste v3.

Pour ref=main avec rerun_group=all, pour les références release/* et pour les références alpha de Tideclaw, une nouvelle exécution globale remplace une exécution plus ancienne ayant la même référence et le même groupe de réexécution. Lorsque le parent est annulé, son moniteur annule tous les workflows enfants qu’il a déjà lancés. Les exécutions de validation épinglées sur un tag ou un SHA ne s’annulent pas entre elles.

Étapes des vérifications de publication

OpenClaw Release Checks est le workflow enfant le plus volumineux. Il résout la cible une seule fois et prépare un artefact partagé release-package-under-test lorsque les étapes liées au paquet ou à Docker en ont besoin.

Segments du parcours de publication Docker

L’étape Docker du parcours de publication exécute les segments suivants lorsque live_suite_filter est vide :

Utilisez docker_lanes=<lane[,lane]> de manière ciblée dans le workflow réutilisable en conditions réelles/E2E lorsqu’un seul parcours Docker a échoué. Les artefacts de publication incluent des commandes de réexécution propres à chaque parcours, avec des paramètres de réutilisation de l’artefact de paquet et de l’image lorsqu’ils sont disponibles.

Profils de publication

release_profile contrôle principalement l’étendue des tests en direct et des fournisseurs dans les vérifications de version. Il ne supprime ni la CI complète normale, ni la préversion des Plugins, ni le test rapide d’installation, ni la validation des paquets, ni QA Lab. Les profils stable et complet exécutent toujours une couverture exhaustive des tests E2E du dépôt/en direct et des tests prolongés du chemin de publication Docker. Le profil bêta peut l’activer avec run_release_soak=true. La validation des paquets fournit le test E2E Telegram canonique du paquet pour chaque candidat complet, de sorte que le workflow global ne duplique pas ce scrutateur en direct.

Ajouts réservés au profil complet

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

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

Réexécutions ciblées

Utilisez rerun_group pour éviter de répéter des environnements de publication sans rapport :

Utilisez live_suite_filter avec rerun_group=live-e2e lorsqu’une seule suite en direct a échoué. Les identifiants de filtre valides sont définis dans le workflow réutilisable en direct/E2E, 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 réexécution agrégé pour ses trois fragments de fournisseurs ; il continue donc à se déployer sur toutes les tâches consultatives du Gateway Docker.

Utilisez cross_os_suite_filter avec rerun_group=cross-os lorsqu’un parcours multiplateforme a échoué. Le filtre accepte un identifiant de système d’exploitation, un identifiant de suite ou une paire système d’exploitation/suite, par exemple windows/packaged-upgrade, windows ou packaged-fresh. Les résumés multiplateformes incluent les durées par phase pour les parcours de mise à niveau empaquetée, et les commandes de longue durée affichent des lignes de Heartbeat afin qu’une mise à jour bloquée soit visible avant l’expiration de la tâche.

Les échecs des vérifications QA de version bloquent la validation normale de la version. La vérification de couverture des outils d’exécution QA (dérive dynamique des outils entre openclaw et codex dans le niveau standard) bloque également le vérificateur des contrôles de version, même si le parcours sous-jacent de parité d’exécution QA est consultatif. Les exécutions alpha de Tideclaw peuvent toujours traiter comme consultatifs les parcours de vérification de version sans incidence sur la sûreté des paquets. Avec release_profile=beta, les suites de fournisseurs en direct de Run repo/live E2E validation sont consultatives : les déploiements de modèles tiers évoluent indépendamment d’une version, si bien que le profil bêta signale leurs échecs sous forme d’avertissements, tandis que les profils stable et complet les conservent comme bloquants. Lorsque live_suite_filter demande explicitement un parcours QA en direct soumis à activation, tel que Discord, WhatsApp ou Slack, la variable de dépôt OPENCLAW_RELEASE_QA_*_LIVE_CI_ENABLED correspondante doit être activée ; sinon, la saisie des paramètres échoue au lieu d’ignorer silencieusement le parcours. Réexécutez rerun_group=qa, qa-parity ou qa-live lorsque vous avez besoin de nouvelles preuves QA.

Preuves à conserver

Conservez le résumé Full Release Validation comme index au niveau de la version. Il fournit des liens vers les identifiants d’exécution des workflows enfants et inclut des tableaux des tâches les plus lentes. En cas d’échec, inspectez d’abord le workflow enfant, puis réexécutez le plus petit identifiant correspondant ci-dessus.

Artefacts utiles :

• release-package-under-test provenant de OpenClaw Release Checks
• Artefacts du chemin de publication Docker sous .artifacts/docker-tests/
• Artefacts package-under-test et de validation Docker de la validation des paquets
• Artefacts de vérification de version multiplateforme pour chaque système d’exploitation et chaque suite
• Artefacts de parité QA, de parité d’exécution, 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/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