Full Release Validation is de overkoepelende productvalidatie voor releases. Het meeste werk
vindt plaats in onderliggende workflows, zodat een mislukte omgeving opnieuw kan worden uitgevoerd zonder de
volledige release opnieuw te starten. Voer de releasevoorbereiding uit voordat je de Code SHA vastlegt; deze
vernieuwt de locale-uitvoer van de Control UI wanneer de achtergrondbot deze nog niet heeft
opgeleverd en dwingt vervolgens dezelfde strikte controle zonder fallbacks af die door release-CI wordt gebruikt.
Leg de productvolledige commit van vóór de changelog vast als de Code SHA en voer vervolgens uit:
provider accepteert ook anthropic of minimax voor onboarding op meerdere besturingssystemen en de
end-to-end agentbeurt. De helper leidt het profiel beta af uit alfa-/bèta-
pakketversies en anders stable. Geef alternatieve workflowinvoer door met
-f key=value; gebruik -f release_profile=full alleen voor de brede adviescontrole.
De helper maakt een tijdelijke release-ci/*-ref die is vastgezet op één vertrouwde
origin/main-workflow-SHA, geeft de doel-SHA alleen door als de kandidaat-ref
en verwijdert de tijdelijke ref na validatie. Elke gestarte onderliggende workflow moet
dezelfde workflow-SHA rapporteren. 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
repositoryrefs.
Uitzondering voor extended-stable
Voor publicatie van extended-stable is een uitvoering vereist waarvan zowel de workflow als het doel de canonieke branch is:pnpm ci:full-release of release-ci/* niet. De publicatie koppelt de
branch, head-/doel-SHA, manifest-workflowRef, ID en poging van de uitvoering aan de canonieke
branch en releasecommit.
Backport productfouten; voer voor tooling met een vastgelegd doel de kleinste reparatie uit die
het gedrag behoudt; probeer provider-, goedkeurings- of runnerfouten opnieuw zonder
bronwijziging. Elke branchwijziging vereist een volledig nieuwe uitvoering. Laat vereiste
pakket-, installatieprogramma-, update-, kanaal- of livefunctionaliteit niet weg omdat het doel oud is.
Wanneer de Code SHA voor een reguliere release groen is, genereer en commit je alleen
CHANGELOG.md. Deze nieuwe commit is de Release SHA. Voer dezelfde helper uit voor
de Release SHA. Productbewijs wordt alleen hergebruikt wanneer GitHub bewijst dat de Release
SHA afstamt van de Code SHA en de volledige verzameling gewijzigde paden exact
CHANGELOG.md is; de npm-preflight en acceptatie van pakket/installatie worden nog steeds uitgevoerd op de
Release SHA.
release_profile=stable en release_profile=full voeren altijd de uitgebreide
live-/Docker-duurtest uit. Geef run_release_soak=true door om dezelfde duurtestlanes
op te nemen met het profiel beta. Stabiele publicatie weigert een validatiemanifest
zonder deze duurtest en blokkerend bewijs van productprestaties.
Package Acceptance bouwt het kandidaattarball normaal vanuit de opgeloste
ref, inclusief uitvoeringen met volledige SHA die met pnpm ci:full-release zijn gestart. Geef na een
bètapublicatie release_package_spec=openclaw@YYYY.M.PATCH-beta.N door om
het uitgebrachte npm-pakket te hergebruiken voor releasecontroles, Package Acceptance, meerdere besturingssystemen,
het Docker-releasepad en pakket-Telegram. Gebruik package_acceptance_package_spec
alleen wanneer Package Acceptance bewust een ander pakket moet aantonen.
De livepakketlane van 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 vanuit de geselecteerde ref; en operators
kunnen codex_plugin_spec rechtstreeks instellen voor npm:-, npm-pack:- of git:-pluginbronnen.
De lane verleent de expliciete goedkeuring voor installatie van de Codex CLI die deze plugin vereist,
en voert vervolgens een Codex CLI-preflight en OpenAI-agentbeurten in dezelfde sessie uit.
De laatste beurt zonder nieuwe pogingen en met gemiddeld denkniveau verstuurt zichtbare voortgang met weggelaten
Codex-final, leest willekeurige invoer uit de werkruimte, schrijft het exacte artifact ervan
en verstuurt een expliciete voltooiing. Hiermee wordt de regressie in v2026.7.1 gedetecteerd waarbij het
versturen van gewone voortgang de beurt beëindigde.
Fasen op hoofdniveau
Voorrerun_group=all wordt eerst een Check for reusable validation evidence-job
uitgevoerd. Deze zoekt naar de nieuwste eerdere groene volledige validatie met hetzelfde release-
profiel, dezelfde effectieve duurtestinstelling en dezelfde validatie-invoer. Nieuwe uitvoeringen met exact hetzelfde doel gebruiken
exact-target-full-validation-v1. Een afstammeling waarvan de volledige delta exact
CHANGELOG.md is, gebruikt changelog-only-release-v1; elke productlane wordt overgeslagen
en de verificator controleert onafhankelijk opnieuw de GitHub-commitvergelijking, het onveranderlijke
bovenliggende artifact, de onderliggende uitvoeringen en de dispatchlogboeken. Elke andere doelwijziging vereist
een nieuwe Code SHA-validatie. Geef reuse_evidence=false door om een nieuwe volledige
uitvoering af te dwingen. Bewijshergebruik wordt alleen uitgevoerd vanuit main of een canonieke, op SHA vastgezette
release-ci/*-ref waarvan de workflowcommit deel blijft uitmaken van de vertrouwde main-afstammingslijn;
andere workflowrefs voeren de geselecteerde lanes opnieuw uit.
Nieuwe pakketgerichte validatie bereidt één onveranderlijk tarball en één Docker-
imageartifact voor voordat Plugin Prerelease en OpenClaw Release Checks worden gestart.
Beide onderliggende workflows verifiëren vóór gebruik dezelfde pakket-SHA, artifact-ID’s, servicedigests,
poging van de producerende uitvoering en digest van het Docker-archief. De pakketonafhankelijke
basis-Dockerlaag gebruikt een inhoudsgeadresseerde GHCR-cache; kandidaatspecifieke images
blijven onveranderlijke GitHub-artifacts. Gerichte uitvoeringen met een expliciete specificatie van een gepubliceerd
pakket behouden in plaats daarvan het bestaande pakketpad.
Ook voor rerun_group=all bouwt een Verify Docker runtime image assets-job
het Docker-doel runtime-assets met
OPENCLAW_EXTENSIONS=diagnostics-otel,codex. Deze wordt parallel met de
andere fasen uitgevoerd en door de overkoepelende verificator afgedwongen; lanes wachten er niet langer op
voordat ze worden gestart. Een beperktere rerun_group slaat deze preflight over.
De overkoepelende workflow start productprestaties altijd in de modus met alleen artifacts.
OpenClaw Performance staat rapportpublicatie alleen toe voor geplande uitvoeringen of een
handmatige start waarbij publish_reports=true expliciet is ingesteld. De beveiliging voor
alleen artifacts moet succesvol worden voltooid en daarmee aantonen dat de publicatorjob overgeslagen bleef.
Nieuw en hergebruikt bewijs registreert
controls.performanceReportPublication=artifact-only; de verificator en selector voor hergebruik
weigeren bewijs zonder het overeenkomende genormaliseerde bewijs van de onderliggende prestatieworkflow.
De verifier uploadt het canonieke manifest als
full-release-validation-<run-id>-<run-attempt>. De tooling voor bewijsmateriaal valideert
de artefact-ID, digest, producerende run en poging voordat exact die
artefact-ID wordt gedownload. De tooling begrenst het gedownloade ZIP-bestand, verifieert de bytes ervan aan de hand van de REST-
sha256:-digest en streamt de enige toegestane begrensde manifestvermelding zonder
het archief uit te pakken. Een alias met een stabiele naam blijft tijdelijk bestaan voor oudere
publicatieconsumenten. De verifier geeft altijd de voorkeur aan het aan de poging gekoppelde artefact;
als overgang accepteert deze de stabiele naam alleen voor een poging-1-producent van manifest v2.
De verifier weigert die verouderde naam voor latere pogingen en manifest v3.
Voor ref=main met rerun_group=all, voor release/*-refs en voor Tideclaw-
alfarefs vervangt een nieuwere overkoepelende run een oudere met dezelfde ref en
herstartgroep. Wanneer de bovenliggende run wordt geannuleerd, annuleert de monitor ervan elke onderliggende
workflow die al is gestart. Validatieruns voor tags en vastgezette SHA’s
annuleren elkaar niet.
Fasen van releasecontroles
OpenClaw Release Checks is de grootste onderliggende workflow. Deze bepaalt het doel
eenmalig en valideert het gedeelde pakketartefact van de overkoepelende workflow wanneer dit beschikbaar is. Een
directe of gerichte dispatch bereidt een eigen release-package-under-test-
artefact voor wanneer pakket- of Docker-gerichte fasen dit nodig hebben.
Docker-chunks voor het releasepad
De Docker-releasepadfase voert deze chunks uit wanneerlive_suite_filter
leeg is:
Gebruik gerichte
docker_lanes=<lane[,lane]> in de herbruikbare live/E2E-workflow wanneer
slechts één Docker-lane is mislukt. De releaseartefacten bevatten per lane
opdrachten voor opnieuw uitvoeren, met invoer voor hergebruik van pakketartefacten en images indien beschikbaar.
Releaseprofielen
release_profile bepaalt voornamelijk de breedte van live/providers binnen releasecontroles.
Het verwijdert geen normale volledige CI, Plugin Prerelease, installatiesmoke, pakketacceptatie
of QA Lab. Stabiele en volledige profielen voeren altijd uitputtende repo/live-
E2E- en Docker-releasepad-soakdekking uit. Het bètaprofiel kan dit inschakelen met
run_release_soak=true. Package Acceptance levert de canonieke pakket-
Telegram-E2E voor elke volledige kandidaat, zodat de overkoepelende workflow die
live-poller niet dupliceert.
Toevoegingen alleen voor volledig
Deze suites worden overgeslagen doorstable en opgenomen door full:
stable omvat 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 nieuwe uitvoeringen kunnen nog steeds de
geaggregeerde handles native-live-src-gateway-profiles-anthropic of
native-live-src-gateway-profiles-opencode-go gebruiken.
Gerichte nieuwe uitvoeringen
Gebruikrerun_group om te voorkomen dat niet-gerelateerde releaseboxen 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.
Stel voor een gerichte nieuwe uitvoering van een QA-transport rerun_group=qa-live in en gebruik de
canonieke selector qa-live-matrix, qa-live-telegram, qa-live-discord,
qa-live-whatsapp of qa-live-slack.
De handle live-gateway-advisory-docker is een geaggregeerde handle voor het opnieuw uitvoeren van de
drie providershards en vertakt daarom nog steeds naar alle adviserende Docker-Gateway-taken.
Gebruik cross_os_suite_filter met rerun_group=cross-os wanneer één lane voor meerdere besturingssystemen
is mislukt. Het filter accepteert een besturingssysteem-id, een suite-id of een combinatie van besturingssysteem/suite, bijvoorbeeld
windows/packaged-upgrade, windows of packaged-fresh. Samenvattingen voor meerdere besturingssystemen
bevatten timings per fase voor verpakte upgradelanes, en langlopende
opdrachten drukken Heartbeat-regels af, zodat een vastgelopen update zichtbaar is vóór de
taaktime-out.
Mislukte QA-releasecontroles blokkeren normale releasevalidatie alleen voor geselecteerde
lanes voor Matrix, Telegram en dekking van QA-runtimetools. QA-pariteit, runtime-
pariteit en de afgeschermde live lanes voor Discord, WhatsApp en Slack zijn adviserend en
publiceren statusartefacten zonder de releaseverificatie te blokkeren. Tideclaw-
alphauitvoeringen kunnen releasecontroles 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 tijdens een release, dus
beta geeft hun fouten weer als waarschuwingen, terwijl stabiele en volledige profielen
ze blokkerend houden. Wanneer
live_suite_filter expliciet een afgeschermde live QA-lane aanvraagt, zoals Discord,
WhatsApp of Slack, moet de bijbehorende repo-
variabele OPENCLAW_RELEASE_QA_*_LIVE_CI_ENABLED zijn ingeschakeld; anders mislukt het vastleggen van de invoer in plaats van de lane stilzwijgend over te slaan.
Voer rerun_group=qa, qa-parity of qa-live opnieuw uit wanneer je
nieuw QA-bewijs nodig hebt.
Te bewaren bewijs
Bewaar de samenvattingFull Release Validation als index op releaseniveau. Deze koppelt
child-uitvoerings-id’s en bevat tabellen met de langzaamste taken. Inspecteer bij fouten eerst de child-
workflow en voer vervolgens de kleinste overeenkomende handle hierboven opnieuw uit.
Leg voor een reguliere release zowel de Code SHA als de Release SHA vast, evenals het hergebruikbeleid
en de set gewijzigde paden, de groene parent-uitvoering van de Code SHA en de lichtgewicht parent-
uitvoering van de Release SHA. Leg voor extended-stable de canonieke branch, de exacte release-
SHA, de nieuwe parent-uitvoerings-id en poging, de workflowreferentie, elke child-uitvoering en eventuele
compatibiliteitsreparaties voor het bevroren doel of bewuste weglatingen vast.
Nuttige artefacten:
release-package-under-testuitOpenClaw Release Checks- Docker-releasepadartefacten onder
.artifacts/docker-tests/ - Package Acceptance
package-under-testen Docker-acceptatieartefacten - Artefacten van releasecontroles voor meerdere besturingssystemen voor elk besturingssysteem en elke suite
- QA-pariteit, runtimepariteit en geselecteerde artefacten voor Matrix, Telegram, Discord, WhatsApp of Slack
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