Testen: updates en plugins

Dit is de speciale checklist voor update- en Plugin-validatie. Het doel is eenvoudig: bewijzen dat het installeerbare pakket echte gebruikersstatus kan bijwerken, verouderde legacy-status via doctor kan repareren, en nog steeds plugins uit de ondersteunde bronnen kan installeren, laden, bijwerken en verwijderen.

Zie Testen voor de bredere kaart van de test runner. Zie Live testen voor live providersleutels en suites die het netwerk raken.

Wat we beschermen

Update- en Plugin-tests beschermen deze contracten:

• Een pakket-tarball is compleet, heeft een geldige dist/postinstall-inventory.json, en is niet afhankelijk van uitgepakte repobestanden.
• Een gebruiker kan van een ouder gepubliceerd pakket naar het kandidaatpakket gaan zonder config, agents, sessies, workspaces, Plugin-allowlists of kanaalconfiguratie te verliezen.
• openclaw doctor --fix --non-interactive is eigenaar van legacy-opruim- en reparatiepaden. Startup mag geen verborgen compatibiliteitsmigraties voor verouderde Plugin-status krijgen.
• Plugin-installaties werken vanuit lokale mappen, git-repo's, npm-pakketten en het ClawHub-registrypad.
• Plugin npm-afhankelijkheden worden geinstalleerd in een beheerd npm-project per Plugin, gescand voor vertrouwen, en via npm verwijderd tijdens uninstall zodat gehesen afhankelijkheden niet blijven hangen.
• Plugin-update is stabiel wanneer er niets is gewijzigd: installatierecords, opgeloste bron, geinstalleerde afhankelijkheidslayout en ingeschakelde status blijven intact.

Lokale proof tijdens ontwikkeling

Begin smal:

pnpm changed:lanes --jsonpnpm check:changedpnpm test:changed

Voer voor wijzigingen aan Plugin-installatie, uninstall, afhankelijkheden of pakket-inventory ook de gerichte tests uit die de bewerkte seam afdekken:

pnpm test src/plugins/uninstall.test.ts src/infra/package-dist-inventory.test.ts test/scripts/package-acceptance-workflow.test.ts

Voordat een package Docker-lane een tarball gebruikt, bewijs je het pakketartefact:

pnpm release:check

release:check voert driftcontroles voor config/docs/API uit, schrijft de package dist-inventory, voert npm pack --dry-run uit, weigert verboden ingepakte bestanden, installeert de tarball in een tijdelijke prefix, voert postinstall uit en rooktest gebundelde kanaal-entrypoints.

Docker-lanes

De Docker-lanes zijn de productniveau-proof. Ze installeren of updaten een echt pakket in Linux-containers en controleren gedrag via CLI-commando's, Gateway-startup, HTTP-probes, RPC-status en bestandssysteemstatus.

Gebruik gerichte lanes tijdens iteratie:

pnpm test:docker:pluginspnpm test:docker:plugin-lifecycle-matrixpnpm test:docker:plugin-updatepnpm test:docker:upgrade-survivorpnpm test:docker:published-upgrade-survivorpnpm test:docker:update-restart-authpnpm test:docker:update-migration

Belangrijke lanes:

• test:docker:plugins valideert Plugin-installatierooktest, lokale-mapinstallaties, skipgedrag voor lokale-mapupdates, lokale mappen met vooraf geinstalleerde afhankelijkheden, file:-pakketinstallaties, git-installaties met CLI-uitvoering, git moving-ref-updates, npm-registry-installaties met gehesen transitieve afhankelijkheden, npm-update-no-ops, weigering van misvormde npm-pakketmetadata, installaties van lokale ClawHub-fixtures en update-no-ops, marketplace-updategedrag, en Claude-bundle enable/inspect. Zet OPENCLAW_PLUGINS_E2E_CLAWHUB=0 om het ClawHub-blok hermetisch/offline te houden.
• test:docker:plugin-lifecycle-matrix installeert het kandidaatpakket in een kale container, voert een npm-Plugin door install, inspect, disable, enable, expliciete upgrade, expliciete downgrade en uninstall na het verwijderen van de Plugin-code. Het logt RSS- en CPU-metrics voor elke fase.
• test:docker:plugin-update valideert dat een ongewijzigde geinstalleerde Plugin niet opnieuw installeert of installatiemetadata verliest tijdens openclaw plugins update.
• test:docker:upgrade-survivor installeert de kandidaat-tarball over een vuile old-user-fixture, voert pakketupdate plus non-interactive doctor uit, start daarna een loopback-Gateway en controleert statusbehoud.
• test:docker:published-upgrade-survivor installeert eerst een gepubliceerde baseline, configureert die via een ingebakken openclaw config set-recept, werkt die bij naar de kandidaat-tarball, voert doctor uit, controleert legacy-opruiming, start de Gateway en probet /healthz, /readyz en RPC-status.
• test:docker:update-restart-auth installeert het kandidaatpakket, start een beheerde token-auth Gateway, wist gateway-auth-env van de caller voor openclaw update --yes --json, en vereist dat het updatecommando van de kandidaat de Gateway herstart voor de normale probes.
• test:docker:update-migration is de cleanup-zware published-update-lane. Die begint met een geconfigureerde Discord/Telegram-achtige gebruikersstatus, voert baseline-doctor uit zodat geconfigureerde Plugin-afhankelijkheden kans krijgen te materialiseren, seedt legacy Plugin-afhankelijkheidsresten voor een geconfigureerde packaged Plugin, werkt bij naar de kandidaat-tarball, en vereist dat post-update doctor de legacy-afhankelijkheidsroots verwijdert.

Nuttige varianten van published-upgrade survivor:

OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC=openclaw@2026.4.23 \OPENCLAW_UPGRADE_SURVIVOR_SCENARIO=versioned-runtime-deps \pnpm test:docker:published-upgrade-survivor OPENCLAW_UPGRADE_SURVIVOR_BASELINE_SPEC=openclaw@latest \OPENCLAW_UPGRADE_SURVIVOR_SCENARIO=bootstrap-persona \pnpm test:docker:published-upgrade-survivor

Beschikbare scenario's zijn base, feishu-channel, bootstrap-persona, plugin-deps-cleanup, configured-plugin-installs, stale-source-plugin-shadow, tilde-log-path en versioned-runtime-deps. In samengevoegde runs breidt OPENCLAW_UPGRADE_SURVIVOR_SCENARIOS=reported-issues uit naar alle gerapporteerde issue-vormige scenario's, inclusief de configured-plugin-install-migratie.

Volledige updatemigratie is bewust gescheiden van Full Release CI. Gebruik de handmatige Update Migration-workflow wanneer de releasevraag is: "kan elke gepubliceerde stabiele release vanaf 2026.4.23 bijwerken naar deze kandidaat en Plugin-afhankelijkheidsresten opruimen?":

gh workflow run update-migration.yml \  --ref main \  -f workflow_ref=main \  -f package_ref=main \  -f baselines=all-since-2026.4.23 \  -f scenarios=plugin-deps-cleanup

Package Acceptance

Package Acceptance is de GitHub-native pakketpoort. Het lost een kandidaatpakket op naar een package-under-test-tarball, registreert versie en SHA-256, en voert daarna herbruikbare Docker E2E-lanes uit tegen precies die tarball. De workflow-harness-ref staat los van de pakketbron-ref, zodat huidige testlogica oudere vertrouwde releases kan valideren.

Kandidaatbronnen:

• source=npm: valideer openclaw@beta, openclaw@latest of een exacte gepubliceerde versie.
• source=ref: pak een vertrouwde branch, tag of commit met de geselecteerde huidige harness.
• source=url: valideer een publieke HTTPS-tarball met vereiste package_sha256. Dit pad weigert URL-credentials, niet-standaard HTTPS-poorten, private/interne hostnames of DNS/IP-resultaten, special-use IP-ruimte en onveilige redirects.
• source=trusted-url: valideer een HTTPS-tarball met vereiste package_sha256 en trusted_source_id tegen het maintainer-owned beleid in .github/package-trusted-sources.json. Gebruik dit voor enterprise/private mirrors in plaats van source=url te verzwakken met een allow-private-switch op inputniveau. Bearer-auth gebruikt, wanneer geconfigureerd door beleid, het vaste OPENCLAW_TRUSTED_PACKAGE_TOKEN-secret.
• source=artifact: hergebruik een tarball die door een andere Actions-run is geupload.

Full Release Validation gebruikt standaard source=artifact, gebouwd vanaf de opgeloste release-SHA. Geef voor post-publish-proof package_acceptance_package_spec=openclaw@YYYY.M.PATCH mee zodat dezelfde upgradematrix in plaats daarvan het verzonden npm-pakket target.

Releasecontroles roepen Package Acceptance aan met de package/update/restart/plugin-set:

doctor-switch update-channel-switch update-corrupt-plugin upgrade-survivor published-upgrade-survivor update-restart-auth plugins-offline plugin-update

Wanneer release-soak is ingeschakeld, geven ze ook door:

published_upgrade_survivor_baselines=last-stable-4 2026.4.23 2026.5.2 2026.4.15published_upgrade_survivor_scenarios=reported-issuestelegram_mode=mock-openai

Dit houdt pakketmigratie, updatekanaalwisseling, tolerantie voor corrupte managed-plugins, opruiming van verouderde Plugin-afhankelijkheden, offline Plugin-dekking, Plugin-updategedrag en Telegram package QA op hetzelfde opgeloste artefact zonder dat de standaard releasepakketpoort elke gepubliceerde release doorloopt.

last-stable-4 lost op naar de vier nieuwste stabiele npm-gepubliceerde OpenClaw-releases. Release package acceptance pint 2026.4.23 als de eerste compatibiliteitsgrens voor Plugin-updates, 2026.5.2 als een Plugin-architecture churn-grens en 2026.4.15 als een oudere 2026.4.1x published-update-baseline; de resolver dedupet pins die al in de nieuwste vier zitten. Gebruik voor uitputtende dekking van gepubliceerde updatemigratie all-since-2026.4.23 in de aparte Update Migration-workflow in plaats van Full Release CI. release-history blijft beschikbaar voor handmatige bredere sampling wanneer je ook het legacy pre-date-anker wilt.

Wanneer meerdere published-upgrade survivor-baselines zijn geselecteerd, shardt de herbruikbare Docker-workflow elke baseline naar zijn eigen gerichte runner-job. Elke baseline-shard voert nog steeds de geselecteerde scenarioset uit, maar logs en artefacten blijven per baseline en wall time wordt begrensd door de langzaamste shard in plaats van een grote seriele job.

Voer handmatig een package-profiel uit wanneer je een kandidaat voor release valideert:

gh workflow run package-acceptance.yml \  --ref main \  -f workflow_ref=main \  -f source=npm \  -f package_spec=openclaw@beta \  -f suite_profile=package \  -f published_upgrade_survivor_baselines="last-stable-4 2026.4.23 2026.5.2 2026.4.15" \  -f published_upgrade_survivor_scenarios=reported-issues \  -f telegram_mode=mock-openai

Gebruik suite_profile=product wanneer de releasevraag MCP-kanalen, cron/subagent-opruiming, OpenAI-webzoekopdrachten of OpenWebUI omvat. Gebruik suite_profile=full alleen wanneer je volledige Docker-dekking van het releasepad nodig hebt.

Release-standaard

Voor release candidates is de standaard proof-stack:

1. pnpm check:changed en pnpm test:changed voor regressies op bronniveau.
2. pnpm release:check voor integriteit van pakketartefacten.
3. Package Acceptance package-profiel of de custom package-lanes van release-check voor install/update/restart/plugin-contracten.
4. Cross-OS releasecontroles voor OS-specifiek installer-, onboarding- en platformgedrag.
5. Live suites alleen wanneer het gewijzigde oppervlak provider- of hosted-servicegedrag raakt.

Op maintainer-machines moeten brede poorten en Docker/package-productproof in Testbox draaien, tenzij expliciet lokale proof wordt gedaan.

Legacy-compatibiliteit

Compatibiliteitsmarge is smal en tijdgebonden:

• Pakketten tot en met 2026.4.25, inclusief 2026.4.25-beta.*, mogen al verzonden pakketmetadatagaten in Package Acceptance tolereren.
• Het gepubliceerde 2026.4.26-pakket mag waarschuwen voor al verzonden lokale buildmetadata-stampbestanden.
• Latere pakketten moeten aan moderne contracten voldoen. Dezelfde gaten falen in plaats van te waarschuwen of over te slaan.

Voeg geen nieuwe startup-migraties toe voor deze oude vormen. Voeg een doctor-reparatie toe of breid die uit, en bewijs die daarna met upgrade-survivor, published-upgrade-survivor of update-restart-auth wanneer het updatecommando eigenaar is van de herstart.

Dekking toevoegen

Wanneer je update- of Plugin-gedrag wijzigt, voeg dekking toe op de laagste laag die om de juiste reden kan falen:

• Zuivere pad- of metadatalogica: unittest naast de bron.
• Pakket-inventaris of gedrag van verpakte bestanden: package-dist-inventory of tarball- checker-test.
• CLI-installatie-/updategedrag: Docker-lane-assertie of fixture.
• Migratiegedrag voor gepubliceerde releases: published-upgrade-survivor-scenario.
• Herstartgedrag in eigendom van update: update-restart-auth.
• Registry-/pakketbrongedrag: test:docker:plugins-fixture of ClawHub- fixtureserver.
• Gedrag van afhankelijkheidsindeling of opschoning: controleer zowel runtime-uitvoering als de bestandssysteemgrens. npm-afhankelijkheden kunnen binnen het door de Plugin beheerde npm-project worden gehesen, dus tests moeten aantonen dat dat project wordt gescand/opgeschoond in plaats van aan te nemen dat alleen de Plugin-pakketlokale node_modules-boom wordt gebruikt.

Houd nieuwe Docker-fixtures standaard hermetisch. Gebruik lokale fixture-registries en neppakketten, tenzij het doel van de test live registry-gedrag is.

Foutentriage

Begin met de artefactidentiteit:

• Package Acceptance resolve_package-samenvatting: bron, versie, SHA-256 en artefactnaam.
• Docker-artefacten: .artifacts/docker-tests/**/summary.json, failures.json, lane-logs en rerun-opdrachten.
• Upgrade-survivor-samenvatting: .artifacts/upgrade-survivor/summary.json, inclusief baselineversie, kandidaatversie, scenario, fasetimings en receptstappen.

Geef de voorkeur aan het opnieuw uitvoeren van exact de mislukte lane met hetzelfde pakketartefact boven het opnieuw uitvoeren van de hele release-umbrella.