Volledige releasevalidatie

Full Release Validation is de overkoepelende releasevalidatie: het centrale handmatige startpunt voor bewijs voorafgaand aan een release. Het meeste werk vindt plaats in onderliggende workflows, zodat een mislukte omgeving opnieuw kan worden uitgevoerd zonder de volledige release opnieuw te starten.

Voer dit uit vanaf een vertrouwde workflowreferentie, doorgaans main, en geef de releasebranch, tag of volledige commit-SHA door als 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 accepteert ook anthropic of minimax voor onboarding op meerdere besturingssystemen en de end-to-end agentbeurt. Herbruikbare onderliggende taken bepalen de aangeroepen workflowharness aan de hand van job.workflow_repository en job.workflow_sha, terwijl de invoer ref de te testen kandidaat selecteert. Zo blijft de huidige vertrouwde validatielogica beschikbaar bij het valideren van een oudere releasebranch of tag.

Elke gestarte onderliggende workflow moet dezelfde workflow-SHA rapporteren als de bovenliggende uitvoering van Full Release Validation. Als main verandert tussen het starten van de bovenliggende en onderliggende workflows, wordt de overkoepelende validatie gesloten afgebroken, zelfs wanneer de onderliggende workflow zelf slaagt. Gebruik voor onveranderlijk bewijs van een exacte commit pnpm ci:full-release --sha <target-sha>. De helper maakt een tijdelijke release-ci/*-referentie die is vastgezet op de huidige vertrouwde origin/main, geeft de doel- SHA uitsluitend door als kandidaat-ref, hergebruikt strikt bewijs voor exact hetzelfde doel wanneer dit beschikbaar is en verwijdert de referentie na validatie. Geef -f reuse_evidence=false door om een nieuwe uitvoering af te dwingen, of --workflow-sha <trusted-main-sha> om een oudere workflowcommit te selecteren die nog bereikbaar is vanaf de huidige origin/main. De workflow maakt of wijzigt zelf nooit repositoryreferenties.

release_profile=stable en release_profile=full voeren altijd de volledige live-/Docker-duurtest uit. Geef run_release_soak=true door om dezelfde duurtesttrajecten ook met het beta-profiel uit te voeren. Stabiele publicatie weigert een validatiemanifest zonder deze duurtest en blokkerend bewijs van productprestaties.

Package Acceptance bouwt normaal gesproken het kandidaat-tarball op basis van de bepaalde ref, waaronder uitvoeringen met een volledige SHA die via pnpm ci:full-release zijn gestart. Geef na een bètapublicatie release_package_spec=openclaw@YYYY.M.PATCH-beta.N door om het gepubliceerde npm-pakket opnieuw te gebruiken voor releasecontroles, Package Acceptance, meerdere besturingssystemen, het Docker-releasetraject en Telegram voor het pakket. Gebruik package_acceptance_package_spec alleen wanneer Package Acceptance bewust een ander pakket moet verifiëren. Het livepakkettraject voor de Codex-Plugin volgt dezelfde status: gepubliceerde release_package_spec-waarden leiden codex_plugin_spec=npm:@openclaw/codex@<version> af; SHA-/artifactuitvoeringen verpakken extensions/codex vanaf de geselecteerde referentie; en beheerders kunnen codex_plugin_spec rechtstreeks instellen voor Plugin-bronnen van het type npm:, npm-pack: of git:. Het traject verleent de expliciete goedkeuring voor de installatie van Codex CLI die voor die Plugin vereist is en voert vervolgens de voorafgaande Codex CLI-controle en OpenAI-agentbeurten binnen dezelfde sessie uit.

Fasen op hoofdniveau

Voor rerun_group=all wordt eerst een taak Check for reusable validation evidence uitgevoerd: deze zoekt naar de nieuwste eerdere geslaagde volledige validatie voor exact dezelfde doel-SHA, hetzelfde releaseprofiel, dezelfde effectieve duurtestinstelling en dezelfde validatie-invoer. Wanneer dergelijk bewijs bestaat, wordt elk traject overgeslagen en controleert de overkoepelende verificateur het onveranderlijke bovenliggende artifact, de onderliggende uitvoeringen en de startlogboeken opnieuw. Dit dient uitsluitend voor herstel door opnieuw uitvoeren met dezelfde kandidaat; hergebruik tussen verschillende SHA's wordt hiermee niet toegestaan. Voer voor een gewijzigde kandidaat elke pakket-, artifact-, installatie-, Docker- of provider- controle opnieuw uit waarop die wijziging invloed heeft. Geef reuse_evidence=false door om een volledig nieuwe uitvoering af te dwingen. Bewijshergebruik wordt alleen uitgevoerd vanaf main of een canonieke, op een SHA vastgezette release-ci/*-referentie waarvan de workflowcommit deel blijft uitmaken van de vertrouwde afstamming van main; andere workflowreferenties voeren de geselecteerde trajecten opnieuw uit.

Eveneens voor rerun_group=all bouwt een taak Verify Docker runtime image assets het Docker-doel runtime-assets met OPENCLAW_EXTENSIONS=diagnostics-otel,codex. Deze wordt parallel met de andere fasen uitgevoerd en door de overkoepelende verificateur afgedwongen; trajecten wachten niet langer op deze taak voordat ze worden gestart. Bij een beperktere rerun_group wordt deze voorafgaande controle overgeslagen.

De overkoepelende validatie start productprestaties altijd in een modus die uitsluitend artifacts produceert. OpenClaw Performance staat rapportpublicatie alleen toe voor geplande uitvoeringen of een handmatig gestarte uitvoering waarbij expliciet publish_reports=true is ingesteld. De beveiliging voor uitsluitend artifacts moet met succes worden voltooid, waarmee wordt bewezen dat de publicatietaak overgeslagen bleef. Nieuw en hergebruikt bewijs registreert controls.performanceReportPublication=artifact-only; de verificateur en selector voor hergebruik weigeren bewijs zonder het bijbehorende genormaliseerde bewijs van de onderliggende prestatieworkflow.

De verificateur uploadt het canonieke manifest als full-release-validation-<run-id>-<run-attempt>. Bewijshulpmiddelen valideren de artifact-ID, digest, producerende uitvoering en poging voordat precies die artifact-ID wordt gedownload. De grootte van het gedownloade ZIP-bestand wordt begrensd, de bytes worden vergeleken met de REST- digest sha256: en het enige toegestane, begrensde manifestitem wordt gestreamd zonder het archief uit te pakken. Een alias met een stabiele naam blijft tijdelijk bestaan voor oudere publicatieconsumenten. De verificateur geeft altijd de voorkeur aan het artifact met een poging in de naam; als overgang accepteert deze de stabiele naam alleen voor een producer van manifest v2 bij poging 1. De legacynaam wordt voor latere pogingen en manifest v3 geweigerd.

Voor ref=main met rerun_group=all, voor release/*-referenties en voor Tideclaw- alfareferenties vervangt een nieuwere overkoepelende uitvoering een oudere met dezelfde referentie en groep voor opnieuw uitvoeren. Wanneer de bovenliggende uitvoering wordt geannuleerd, annuleert de monitor alle reeds gestarte onderliggende workflows. Validatie-uitvoeringen voor tags en vastgezette SHA's annuleren elkaar niet.

Fasen van releasecontroles

OpenClaw Release Checks is de grootste onderliggende workflow. Deze bepaalt het doel eenmaal en bereidt een gedeeld release-package-under-test-artifact voor wanneer pakket- of Docker-gerichte fasen dit nodig hebben.

Docker-chunks voor het releasepad

De Docker-fase voor het releasepad voert deze chunks uit wanneer live_suite_filter leeg is:

Gebruik gerichte docker_lanes=<lane[,lane]> in de herbruikbare live/E2E-workflow wanneer slechts één Docker-traject is mislukt. De releaseartefacten bevatten per traject opdrachten voor opnieuw uitvoeren, met invoer voor hergebruik van pakketartefacten en images wanneer beschikbaar.

Releaseprofielen

release_profile bepaalt voornamelijk de breedte van live-/providercontroles binnen releasecontroles. Het verwijdert geen normale volledige CI, Plugin-voorrelease, installatierooktest, pakketacceptatie of QA Lab. Stabiele en volledige profielen voeren altijd uitgebreide E2E-dekking voor de repo/liveomgeving en duurtests voor het Docker-releasepad uit. Het bètaprofiel kan dit inschakelen met run_release_soak=true. Pakketacceptatie levert de canonieke Telegram-E2E voor pakketten voor elke volledige kandidaat, zodat de overkoepelende workflow die live-poller niet dupliceert.

Toevoegingen uitsluitend voor volledig

Deze suites worden overgeslagen door stable en opgenomen door full:

stable bevat native-live-src-gateway-profiles-anthropic-smoke en native-live-src-gateway-profiles-opencode-go-smoke; full gebruikt in plaats daarvan de bredere modelshards voor Anthropic en OpenCode Go. Gerichte heruitvoeringen kunnen nog steeds de geaggregeerde ingangen native-live-src-gateway-profiles-anthropic of native-live-src-gateway-profiles-opencode-go gebruiken.

Gerichte heruitvoeringen

Gebruik rerun_group om te voorkomen dat niet-gerelateerde releaseomgevingen opnieuw worden uitgevoerd:

Gebruik live_suite_filter met rerun_group=live-e2e wanneer één live-suite is mislukt. Geldige filter-id's zijn gedefinieerd in de herbruikbare live-/E2E-workflow, waaronder 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 en live-codex-harness-docker.

De ingang live-gateway-advisory-docker is een geaggregeerde heruitvoeringsingang voor de drie providershards en wordt dus nog steeds verdeeld over alle adviserende Docker-Gateway-taken.

Gebruik cross_os_suite_filter met rerun_group=cross-os wanneer één testbaan voor meerdere besturingssystemen is mislukt. Het filter accepteert een besturingssysteem-id, een suite-id of een combinatie van besturingssysteem en suite, bijvoorbeeld windows/packaged-upgrade, windows of packaged-fresh. Samenvattingen voor meerdere besturingssystemen bevatten tijdmetingen per fase voor testbanen voor pakketupgrades, en langlopende opdrachten drukken Heartbeat-regels af, zodat een vastgelopen update zichtbaar is voordat de taak een time-out bereikt.

Mislukte QA-releasecontroles blokkeren de normale releasevalidatie. De controle van de runtime-tooldekking van QA (dynamische toolafwijking tussen openclaw en codex in het standaardniveau) blokkeert ook de verificatie van releasecontroles, hoewel de onderliggende testbaan voor runtimepariteit van QA adviserend is. Tideclaw-alfauitvoeringen kunnen releasecontroletestbanen die niet over pakketveiligheid gaan nog steeds als adviserend behandelen. Met release_profile=beta zijn de live-providersuites van Run repo/live E2E validation adviserend: implementaties van modellen van derden veranderen onafhankelijk van een release, waardoor bèta hun fouten als waarschuwingen toont, terwijl stabiele en volledige profielen ze blokkerend houden. Wanneer live_suite_filter expliciet om een afgeschermde live QA-testbaan zoals Discord, WhatsApp of Slack vraagt, moet de bijbehorende repo-variabele OPENCLAW_RELEASE_QA_*_LIVE_CI_ENABLED zijn ingeschakeld; anders mislukt het vastleggen van de invoer in plaats van de testbaan stilzwijgend over te slaan. Voer rerun_group=qa, qa-parity of qa-live opnieuw uit wanneer u actueel QA-bewijs nodig hebt.

Te bewaren bewijs

Bewaar de samenvatting Full Release Validation als index op releaseniveau. Deze bevat koppelingen naar de uitvoerings-id's van subworkflows en tabellen met de langzaamste taken. Inspecteer bij fouten eerst de subworkflow en voer daarna de kleinste overeenkomende ingang hierboven opnieuw uit.

Nuttige artefacten:

• release-package-under-test uit OpenClaw Release Checks
• Artefacten van het Docker-releasepad onder .artifacts/docker-tests/
• package-under-test van pakketacceptatie en Docker-acceptatieartefacten
• Artefacten van releasecontroles voor meerdere besturingssystemen voor elk besturingssysteem en elke suite
• Artefacten voor QA-pariteit, runtimepariteit, Matrix en Telegram

Workflowbestanden

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