Tests de pré-lancement des plugins OpenClaw

Que fait Tests de pré-lancement des plugins OpenClaw ?

Utilisez ce skill lorsque l'utilisateur demande une confiance de lancement de plugin, des analyses du cycle de vie des plugins, une preuve de l'artefact de paquet-plugin, ou « quoi d'autre devrions-nous tester avant le lancement ? ». Il complète openclaw-testing ; utilisez également ce skill lorsque vous choisissez le runner sécurisé le moins coûteux ou que vous déboguez une voie défaillante.

Objectif

Prouver le système de plugins en tant que surface produit, pas seulement en tant que tests source :

• cycle de vie des plugins intégrés : installer, inspecter, activer, désactiver, désinstaller
• comportement des artefacts de paquets depuis un HOME propre
• validation et idempotence de doctor/fix/config
• découverte de configuration et round-trip de configuration
• visibilité des logs/statut et diagnostics
• démarrage/amorçage de la passerelle avec instantanés de métadonnées de plugins
• compatibilité SDK public pour des plugins externes réels
• sondes fournisseur/canal en condition quasi réelle uniquement lorsque des identifiants sécurisés existent

Premières vérifications

Depuis la racine du dépôt OpenClaw :

pnpm docs:list
git status --short --branch
pnpm changed:lanes --json

Suivez openclaw-testing pour la propriété des dépendances et le choix de la preuve locale ou distante.

Choix du runner

Préférez cet ordre :

1. GitHub Package Acceptance pour la preuve produit du paquet installable.
2. Worker Linux dédié actuel pour la preuve source/paquet/Docker de confiance lorsqu'il possède les dépendances et capacités requises.
3. Testbox ci-build-artifacts-testbox.yml lorsque les voies Docker/paquet ont besoin de caches dist, dist-runtime, et de paquet amorcés.
4. Testbox ci-check-testbox.yml pour les vérifications source, Vitest ciblé, vérifications aux limites du paquet, ou voies Docker ciblées.
5. Commandes ciblées sur poste de travail uniquement pour les petites sondes de format/statique/unité.

Évitez les longues exécutions Docker de paquets à partir d'un arbre de travail partiel obsolète. Si la synchronisation Testbox signale des centaines de fichiers modifiés ou commence à supprimer des entrées de paquets, arrêtez et préparez une nouvelle boîte à partir du main actuel, ou passez à Package Acceptance.

Base existante

Exécutez ou vérifiez ces éléments avant d'inventer une nouvelle couverture :

OPENCLAW_TESTBOX=1 pnpm check:changed
pnpm run test:extensions:package-boundary:canary
pnpm run test:extensions:package-boundary:compile
pnpm test:docker:plugins
OPENCLAW_PLUGINS_E2E_CLAWHUB=0 pnpm test:docker:plugins
pnpm test:docker:plugin-update

Pour une preuve complète d'installation/désinstallation intégrée, partitionnez l'analyse groupée :

OPENCLAW_BUNDLED_PLUGIN_SWEEP_TOTAL=8 \
OPENCLAW_BUNDLED_PLUGIN_SWEEP_INDEX=<0-7> \
pnpm test:docker:bundled-plugin-install-uninstall

Cet exemple partitionne l'inventaire des plugins du paquet sélectionné sur les partitions 0-7. Les plugins QA privés sont en mode source uniquement, sauf si un paquet les inclut explicitement.

Matrice de confiance

Utilisez cette matrice pour l'approbation pré-lancement. Enregistrez le succès/échec, l'URL d'exécution/ID Testbox, le SHA/version du paquet, et la raison du saut en condition quasi réelle.

Surface	Preuve	Runner préféré
Artefact de paquet	Package Acceptance suite_profile=package ou voies personnalisées	GitHub Actions
Cycle de vie intégré	test:docker:bundled-plugin-install-uninstall partitionné	Testbox ou Docker de lancement
Plugins externes	test:docker:plugins et plugins-offline	Testbox/package acceptance
Mise à jour sans op	test:docker:plugin-update	Testbox/package acceptance
Doctor/fix	configs erronées amorcées + doctor --fix --non-interactive	nouveau harnais Docker/Testbox
Round-trip config	config set/get, inspecter, doctor, recharger, diff de hachage	nouveau harnais Docker/Testbox
Bootstrap passerelle	HOME propre, groupes de plugins activés/désactivés, JSON de statut	nouveau harnais Docker/Testbox
Compatibilité SDK	Plugins externes (répertoire, tgz, file:) utilisant des sous-chemins SDK	test:docker:plugins plus nouvelle fumée
Condition quasi réelle	Sondes fournisseur/canal expurgées uniquement pour env. présente	Voies Testbox live

Plan Package Acceptance

La validation complète de lancement (Full Release Validation) possède la qualification finale du candidat avec Q=C et les tarballs de publication exacts. Utilisez Package Acceptance de manière autonome pour les diagnostics ou la confiance post-publication, et non comme qualification de remplacement du candidat :

gh workflow run package-acceptance.yml \
  --repo openclaw/openclaw \
  --ref main \
  -f workflow_ref=main \
  -f source=ref \
  -f package_ref=<branche-ou-sha> \
  -f suite_profile=custom \
  -f docker_lanes='plugins-offline plugin-update doctor-switch update-channel-switch config-reload mcp-channels npm-onboard-channel-agent' \
  -f telegram_mode=mock-openai

Utilisez source=npm -f package_spec=openclaw@beta pour une preuve de bêta publiée. Ces exécutions de diagnostic/confiance autonomes peuvent utiliser le code de harnais actuel de confiance ; la qualification du candidat doit conserver le harnais gelé du candidat à la place.

Pour la publication partagée étendue-stable, exigez une validation complète de lancement exacte cible à partir du harnais release-ci/* appartenant au candidat admis à Q=C, avec un outil de publication et d'admission P distinct. Les producteurs directs de branche canonique ou main ne satisfont pas l'éditeur protégé. Package Acceptance est une fumée de sélecteur post-publication :

gh workflow run package-acceptance.yml \
  --repo openclaw/openclaw \
  --ref main \
  -f workflow_ref=main \
  -f source=npm \
  -f package_spec=openclaw@extended-stable \
  -f suite_profile=package \
  -f telegram_mode=mock-openai

Enregistrez la version résolue. Vérifiez toujours chaque paquet et sélecteur dans l'inventaire all-publishable du tag ; une seule fumée ne remplace pas une relecture de registre.

Qualification des artefacts npm des plugins

Pour un candidat à la publication, la validation complète de lancement (Full Release Validation) possède la qualification des artefacts npm des plugins. Fournissez sa sélection de publication au moment du déclenchement ; le parent de tous les groupes appelle plugin-npm-release.yml en mode artefact uniquement contre le SHA exact de la version, exige une relecture réussie du tarball, et enregistre le descripteur agrégé immuable dans publicationArtifacts.pluginNpm. La préparation de la version et la publication doivent adopter ce descripteur exact plutôt que de recompresser les plugins.

Utilisez un prévol de workflow de confiance autonome uniquement pour un diagnostic ciblé ou une réparation de plugin sélectionné en dehors d'un candidat de publication régulier :

release_sha="$(git rev-parse origin/release/2026.7.1)"
gh workflow run plugin-npm-release.yml \
  --repo openclaw/openclaw \
  --ref main \
  -f preflight_only=true \
  -f publish_scope=selected \
  -f plugins=@openclaw/meta-provider \
  -f ref="${release_sha}" \
  -f npm_dist_tag=default

Ne passez pas release_publish_run_id. Exigez que le workflow termine verify_plugin_npm_preflight avec succès. Enregistrez l'URL d'exécution, le SHA du workflow et le SHA source. Le workflow crée d'abord l'artefact de staging/relecture plugin-npm-package-source-<source-sha>-<extension-id> contenant npm-pack.json, preflight-manifest.json, et le tarball. Il téléverse ensuite l'artefact consommateur final plugin-npm-package-<extension-id>-<version>-<route>-<run-id>-<attempt> contenant le tarball et plugin-publication-manifest.json.

Enregistrez séparément le nom et le condensé de l'artefact final. Le manifeste utilise openclaw.plugin-publication-artifact/v1 et enregistre le SHA cible, les hachages du manifeste du paquet, la route et la politique de publication, ainsi que les hachages et l'inventaire du tarball. Cette preuve autonome est uniquement une validation ; elle n'autorise ni ne prépare la publication et ne peut pas remplacer le descripteur lié au manifeste de la validation complète de lancement. L'inventaire des artefacts, plutôt que l'arborescence source décompressée, constitue la frontière de sécurité et de contenu du paquet : les fixtures source uniquement sont sans importance. Les chemins de test et de fixture appartenant au paquet en dehors des actifs d'exécution et de compétence expédiés échouent à la qualification ; l'exécution expédiée reste soumise à une analyse de sécurité. Les node_modules intégrés restent avec la preuve de dépendance plutôt que la politique de source de plugin. La vérification OIDC distincte trusted_publisher_preflight=true nécessite un tag de déclenchement protégé release-publish/<tooling-sha12>-<epoch> et s'exécute dans npm-publish. La publication réelle nécessite également ce tag d'outillage ; un déclenchement humain direct attend son job d'approbation npm-release avant de publier. Pour une version déjà publiée, exigez que dist.integrity et dist.shasum de npm correspondent au tarball vérifié. Traitez uniquement les tags de distribution manquants ou prouvablement plus anciens comme réparables ; les sélecteurs plus récents ou incomparables sont un blocage.

Nouveau plan de harnais Testbox

Si davantage de certitude est nécessaire, ajoutez ou exécutez une voie Docker plugin-lifecycle-matrix qui utilise un tarball de paquet et des listes de plugins partitionnées. Par plugin :

1. Commencez avec un HOME propre.
2. Capturez plugins list --json.
3. plugins install <id>.
4. plugins inspect <id> --json.
5. plugins disable <id>, puis affirmez la visibilité désactivée.
6. plugins enable <id>, sauf pour les plugins nécessitant une configuration sans config.
7. plugins registry --refresh.
8. doctor --non-interactive.
9. plugins uninstall <id> --force.
10. Affirmez que la valeur plugins.entries du plugin est exactement { enabled: false }, tandis que ses entrées allow/deny, enregistrement d'installation, répertoire géré et chemins de chargement d'exécution intégrés ont disparu. Utilisez les attentes de désinstallation qualifiées par source du harnais existant pour les cibles historiques.
11. Affirmez que les diagnostics ne contiennent aucun level: "error" et que la sortie masque les valeurs d'apparence secrète.

Gardez memory-lancedb spécial : il nécessite une configuration. Affirmez d'abord que l'installation ne l'active pas sans config intégrée, puis exécutez un second cas configuré.

Matrice Doctor/Fix

Amorcez des états erronés et exigez que doctor --fix --non-interactive les répare, puis exécutez à nouveau doctor et exigez l'idempotence :

• plugins.allow obsolète
• plugins.entries obsolète
• config de canal obsolète pour plugin de canal manquant
• plugins.entries.<id>.config invalide
• chemin intégré dans plugins.load.paths
• plugins.installs hérité
• config de canal/plugin désactivé qui ne doit pas préparer les dépendances d'exécution
• arbre de paquet global appartenant à root qui doit rester non modifié

Matrice de bootstrap de passerelle

Démarrez OpenClaw empaqueté dans Docker avec un état propre :

• plugins fournisseur activés, pas d'identifiants : prêt avec avertissements, pas de crash
• plugins de canal configurés désactivés : aucune dépendance d'exécution préparée
• plugins d'activation au démarrage activés : prêt et reflété dans le statut
• config de plugin unique invalide : plugin erroné ignoré/mis en quarantaine, les autres restent

Affirmez :

• la passerelle atteint l'état prêt
• openclaw status --json inclut les diagnostics des plugins
• openclaw plugins inspect --all --json est analysable
• l'arbre de paquet n'est pas modifié
• les logs ne contiennent aucun jeton brut

Représentants du round-trip de configuration

Utilisez des familles de plugins représentatives au lieu de chaque plugin pour un round-trip de configuration approfondi :

• fournisseurs : openai, anthropic, mistral, openrouter
• canaux : telegram, discord, slack, whatsapp
• mémoire : memory-lancedb
• fonctionnalité/exécution : browser, acpx, tokenjuice

Pour chaque représentant :

1. Écrivez la configuration via CLI lorsque c'est possible.
2. Relisez-la via config get ou JSON.
3. Exécutez plugins inspect.
4. Exécutez doctor --non-interactive.
5. Déclenchez le rechargement de configuration de la passerelle si applicable.
6. Comparez le hachage de configuration avant/après les commandes sans opération.

Fumée SDK externe

Dans une voie Docker de paquet, créez de minuscules plugins externes et installez-les à partir de :

• répertoire local
• .tgz
• spécification npm file:

Couvez les formes CJS et ESM, plus au moins un plugin important des sous-chemins ciblés openclaw/plugin-sdk/*. Affirmez que plugins inspect voit son outil, sa méthode de passerelle, sa commande CLI ou son service.

Règles des sondes en condition quasi réelle

Avant un travail en condition quasi réelle, sourcez les env autorisées dans Testbox et générez une matrice de disponibilité expurgée : présente/absente uniquement, jamais de valeurs.

Exécutez uniquement des sondes pour les identifiants qui existent. Préférez les sondes d'authentification/catalogue/statut à l'envoi de messages visibles par l'utilisateur. Si une sonde pourrait contacter un utilisateur externe, un canal ou un espace de travail, arrêtez-vous et demandez à l'utilisateur.

Rapport

Rapportez sous cette forme :

paquet/réf :
ids tbx / urls d'exécution :
matrice :
  cycle de vie intégré :
  acceptance paquet :
  doctor/fix :
  bootstrap passerelle :
  round-trip config :
  sdk externe :
  condition quasi réelle :
échecs :
sauts :
prochain écart de plus haute valeur :

Dites clairement lorsqu'un échec est dû à des dommages de synchronisation/env Testbox plutôt qu'à un comportement produit, et prouvez-le avec une nouvelle exécution propre ou une comparaison avec le main actuel.