Validation complète de la version

Full Release Validation est le cadre global de publication. C’est le point d’entrée manuel unique pour les preuves de prépublication, mais l’essentiel du travail s’exécute dans des workflows enfants afin qu’une machine en échec puisse être relancée sans redémarrer toute la publication.

Exécutez-le depuis une référence de workflow fiable, normalement main, et passez la branche de publication, le tag ou le SHA de commit complet comme 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

Les workflows enfants utilisent la référence de workflow fiable pour le harnais et l’entrée ref pour le candidat testé. Cela rend la nouvelle logique de validation disponible lors de la validation d’une ancienne branche ou d’un ancien tag de publication.

release_profile=stable et release_profile=full exécutent toujours le test d’endurance live/Docker exhaustif. Passez run_release_soak=true pour inclure les mêmes voies d’endurance avec le profil bêta. La publication stable rejette un manifeste de validation sans ce test d’endurance et sans preuves bloquantes de performance produit.

L’acceptation du paquet construit normalement l’archive tar candidate depuis la référence ref résolue, y compris les exécutions sur SHA complet déclenchées avec pnpm ci:full-release. Après une publication bêta, passez release_package_spec=openclaw@YYYY.M.PATCH-beta.N pour réutiliser le paquet npm publié dans les vérifications de publication, l’acceptation du paquet, le cross-OS, Docker du chemin de publication et Telegram du paquet. Utilisez package_acceptance_package_spec uniquement lorsque l’acceptation du paquet doit intentionnellement prouver un paquet différent. La voie du paquet live du Plugin Codex suit le même état : les valeurs publiées de release_package_spec dérivent codex_plugin_spec=npm:@openclaw/codex@<version> ; les exécutions sur SHA/artefact empaquettent extensions/codex depuis la référence sélectionnée ; et les opérateurs peuvent définir directement codex_plugin_spec pour les sources de Plugin npm:, npm-pack: ou git:. La voie accorde l’approbation explicite d’installation du CLI Codex requise par ce Plugin, puis exécute la prévalidation du CLI Codex et des tours d’agent OpenAI dans la même session.

Étapes de premier niveau

Pour ref=main et rerun_group=all, un cadre global plus récent remplace un plus ancien. Lorsque le parent est annulé, son moniteur annule tout workflow enfant qu’il a déjà déclenché. Les exécutions de validation de branche et de tag de publication 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 lorsque les étapes orientées paquet ou Docker en ont besoin.

Fragments du chemin de publication Docker

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

Utilisez docker_lanes=<lane[,lane]> ciblé sur le workflow live/E2E réutilisable lorsque une seule voie Docker a échoué. Les artefacts de publication 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 publication

release_profile contrôle principalement l’étendue live/fournisseur dans les vérifications de publication. Il ne supprime pas la CI complète normale, Plugin Prerelease, le smoke d’installation, l’acceptation du package ou QA Lab. Les profils stable et complet exécutent toujours une couverture exhaustive E2E dépôt/live et soak du chemin de publication Docker. Le profil bêta peut l’activer avec run_release_soak=true. Package Acceptance fournit l’E2E Telegram de package canonique pour chaque candidat complet, afin que le workflow global ne duplique pas ce poller live.

Ajouts propres à full

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 de modèles Anthropic et OpenCode Go plus larges. 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 version sans rapport :

Utilisez live_suite_filter avec rerun_group=live-e2e lorsqu’une seule suite live a échoué. Les ids 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 shards de fournisseurs ; il se déploie donc toujours vers tous les jobs Gateway Docker consultatifs.

Utilisez cross_os_suite_filter avec rerun_group=cross-os lorsqu’une seule lane multi-OS a échoué. Le filtre accepte un id d’OS, un id de suite ou une paire OS/suite, par exemple windows/packaged-upgrade, windows ou packaged-fresh. Les résumés multi-OS incluent les minutages par phase pour les lanes de mise à niveau empaquetée, et les commandes longues affichent des lignes Heartbeat afin qu’une mise à jour Windows bloquée soit visible avant le délai d’expiration du job.

Les échecs de vérification de version QA bloquent la validation normale de la version. La dérive requise des outils dynamiques OpenClaw dans le niveau standard bloque aussi le vérificateur des vérifications de version. Les exécutions alpha Tideclaw peuvent tout de même traiter les lanes de vérification de version sans risque pour le paquet comme consultatives. Lorsque live_suite_filter demande explicitement une lane QA live protégée comme Discord, WhatsApp ou Slack, la variable de dépôt OPENCLAW_RELEASE_QA_*_LIVE_CI_ENABLED correspondante doit être activée ; sinon la capture de l’entrée échoue au lieu d’ignorer silencieusement la lane. Relancez 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 lie les ids d’exécution enfants et inclut les tableaux des jobs les plus lents. 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 OpenClaw Release Checks
• Artefacts du chemin de version Docker sous .artifacts/docker-tests/
• package-under-test d’acceptation du paquet et artefacts d’acceptation Docker
• Artefacts de vérification de version multi-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