release-openclaw-plugin-testing

Teste de Plugin OpenClaw Pré-Lançamento

Use esta skill quando o usuário perguntar sobre confiança no lançamento de plugins, varreduras de ciclo de vida de plugins, prova de plugin com artefatos de pacote, ou "o que mais devemos testar antes do lançamento?". Ela complementa openclaw-testing; use essa skill também ao escolher o runner seguro mais barato ou depurar uma lane com falha.

Objetivo

Provar o sistema de plugins como uma superfície de produto, não apenas como testes de código-fonte:

• ciclo de vida de plugins agrupados: instalar, inspecionar, ativar, desativar, desinstalar
• comportamento de artefatos de pacote a partir de um HOME limpo
• validação e idempotência de doctor/fix/config
• descoberta e idempotência de configuração (round-trip)
• visibilidade de status/log e diagnóstico
• inicialização do gateway com snapshots de metadados de plugins
• compatibilidade do SDK público para plugins externos reais
• sondagens ao vivo de provedores/canais apenas quando credenciais seguras existem

Primeiras Verificações

A partir da raiz do repositório OpenClaw:

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

Siga openclaw-testing para responsabilidade de dependência e a escolha de prova local ou remota.

Escolha do Runner

Prefira esta ordem:

1. GitHub Package Acceptance para prova de produto com pacotes instaláveis.
2. Worker Linux dedicado atual para prova confiável de código-fonte/pacote/Docker quando ele tiver as dependências e capacidades necessárias.
3. Testbox ci-build-artifacts-testbox.yml quando lanes Docker/pacote precisam de dist, dist-runtime e caches de pacote semeados.
4. Testbox ci-check-testbox.yml para verificações de código-fonte, Vitest direcionado, verificações de limite de pacote ou lanes Docker focadas.
5. Comandos direcionados da estação de trabalho apenas para pequenas sondagens de formato/estático/unidade.

Evite execuções longas de Docker de pacote a partir de uma árvore de trabalho esparsa desatualizada. Se a sincronização do Testbox relatar centenas de arquivos alterados ou começar a excluir entradas de pacote, pare e prepare uma nova box a partir do main atual, ou mude para Package Acceptance.

Linha de Base Existente

Execute ou verifique estes antes de inventar nova cobertura:

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

Para prova completa de instalação/desinstalação agrupada, divida a varredura do pacote:

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

Este exemplo particiona o inventário de plugins do pacote selecionado em partições 0-7. Plugins QA privados são apenas em modo de código-fonte, a menos que um pacote os inclua explicitamente.

Matriz de Confiança

Use esta matriz para aprovação pré-lançamento. Registre aprovado/reprovado, URL de execução/ID do Testbox, SHA do pacote/versão e motivo de live ignorado.

Superfície	Prova	Runner preferido
Artefato de pacote	Package Acceptance suite_profile=package ou lanes customizadas	GitHub Actions
Ciclo de vida agrupado	test:docker:bundled-plugin-install-uninstall em partições	Testbox ou Docker de lançamento
Plugins externos	test:docker:plugins e plugins-offline	Testbox/package acceptance
Atualização no-op	test:docker:plugin-update	Testbox/package acceptance
Doctor/fix	Configs ruins semeadas + doctor --fix --non-interactive	Novo harness Docker/Testbox
Config round-trip	config set/get, inspecionar, doctor, recarregar, diff hash	Novo harness Docker/Testbox
Bootstrap do gateway	HOME limpo, grupos de plugins ativados/desativados, JSON de status	Novo harness Docker/Testbox
Compatibilidade SDK	Plugins externos por diretório, tgz e file: usando subcaminhos do SDK	test:docker:plugins mais novo smoke
Live-ish	Sondagens redigidas de provedor/canal apenas para env presente	Testbox live lanes

Plano de Package Acceptance

A Full Release Validation é responsável pela qualificação final do candidato com Q=C e os tarballs exatos de publicação. Use Package Acceptance autônomo para diagnóstico ou confiança pós-publicação, não como uma qualificação substituta de candidato:

gh workflow run package-acceptance.yml \
  --repo openclaw/openclaw \
  --ref main \
  -f workflow_ref=main \
  -f source=ref \
  -f package_ref=<branch-or-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

Use source=npm -f package_spec=openclaw@beta para prova de beta publicado. Estas execuções de diagnóstico/confiança autônomas podem usar o código do harness confiável atual; a qualificação do candidato deve reter o harness congelado do candidato.

Para publicação compartilhada extended-stable, exija Full Release Validation completa de alvo exato a partir do harness release-ci/* de propriedade do candidato admitido em Q=C, com admissão P confiável e ferramentas de publicação separadas. Produtores diretos de branch canônico ou main não satisfazem o publicador protegido. Package Acceptance é um smoke pós-publicação do seletor:

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

Registre a versão resolvida. Ainda verifique cada pacote e seletor no inventário all-publishable da tag; um smoke não é leitura de registro.

Qualificação de Artefato npm de Plugin

Para um candidato a publicação, a Full Release Validation é responsável pela qualificação do artefato npm do plugin. Forneça sua seleção de publicação no despacho; o pai do grupo all invoca plugin-npm-release.yml em modo somente artefato contra o SHA de lançamento exato, requer leitura bem-sucedida do tarball e registra o descritor agregado imutável em publicationArtifacts.pluginNpm. O Release Prepare e a publicação devem adotar esse descritor exato em vez de reempacotar plugins.

Use um preflight autônomo de workflow confiável apenas para um diagnóstico focado ou um reparo de plugin selecionado que esteja fora de um candidato regular de publicação:

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

Não passe release_publish_run_id. Exija que o workflow termine verify_plugin_npm_preflight com sucesso. Registre a URL de execução, SHA do workflow e SHA da origem. O workflow primeiro cria o artefato de staging/leitura plugin-npm-package-source-<source-sha>-<extension-id> contendo npm-pack.json, preflight-manifest.json e o tarball. Em seguida, ele faz upload do artefato final do consumidor plugin-npm-package-<extension-id>-<version>-<route>-<run-id>-<attempt> contendo o tarball e plugin-publication-manifest.json.

Registre o nome do artefato final e o digest separadamente. O manifesto usa openclaw.plugin-publication-artifact/v1 e registra o SHA alvo, hashes do manifesto do pacote, rota e política de publicação, e hashes e inventário do tarball. Esta prova autônoma é apenas validação; ela não autoriza ou prepara publicação e não pode substituir o descritor vinculado ao manifesto da Full Release Validation. O inventário de artefatos, e não a árvore de origem descompactada, é o limite de segurança e conteúdo do pacote: fixtures apenas de origem são irrelevantes. Caminhos de teste e fixture de propriedade do pacote fora de runtime e ativos de skill enviados falham na qualificação; o runtime enviado permanece escaneado por segurança. node_modules agrupado permanece com evidência de dependência em vez de política de origem do plugin. A verificação OIDC separada trusted_publisher_preflight=true requer uma tag de despacho protegida release-publish/<tooling-sha12>-<epoch> e é executada em npm-publish. A publicação real também requer essa tag de ferramenta; um despacho humano direto aguarda seu trabalho de aprovação npm-release antes de publicar. Para uma versão já publicada, exija que dist.integrity e dist.shasum do npm correspondam ao tarball verificado. Trate apenas dist-tags ausentes ou comprovadamente mais antigas como reparáveis; seletores mais novos ou incomparáveis são um bloqueador.

Plano de Novo Harness Testbox

Se mais certeza for necessária, adicione ou execute uma lane Docker plugin-lifecycle-matrix que usa um tarball de pacote e listas de plugins em partições. Por plugin:

1. Comece com um HOME limpo.
2. Capture plugins list --json.
3. plugins install <id>.
4. plugins inspect <id> --json.
5. plugins disable <id>, então afirme visibilidade desativada.
6. plugins enable <id>, exceto plugins que exigem configuração sem config.
7. plugins registry --refresh.
8. doctor --non-interactive.
9. plugins uninstall <id> --force.
10. Afirme que o valor plugins.entries do plugin é exatamente { enabled: false }, enquanto suas entradas de allow/deny, registro de instalação, diretório gerenciado e caminhos de carga de runtime agrupados desapareceram. Use as expectativas de desinstalação qualificadas por origem do harness existente para alvos históricos.
11. Afirme que os diagnósticos não contêm level: "error" e a saída redige valores com aparência de segredo.

Mantenha memory-lancedb especial: ele exige configuração. Primeiro afirme que a instalação não o ativa sem config incorporada, depois execute um segundo caso configurado.

Matriz Doctor/Fix

Semeie estados ruins e exija que doctor --fix --non-interactive os repare, então execute doctor novamente e exija idempotência:

• plugins.allow desatualizado
• plugins.entries desatualizado
• config de canal desatualizada para plugin de canal ausente
• plugins.entries.<id>.config inválido
• caminho agrupado empacotado em plugins.load.paths
• plugins.installs legado
• config de plugin/canal desativado que não deve preparar deps de runtime
• árvore global de pacotes de propriedade raiz que deve permanecer inalterada

Matriz de Bootstrap do Gateway

Inicie o OpenClaw empacotado em Docker com estado limpo:

• plugins de provedor ativados, sem credenciais: pronto com avisos, sem crash
• plugins de canal configurados como desativados: nenhum dep de runtime preparado
• plugins de ativação na inicialização ativados: pronto e refletido no status
• config de plugin único inválida: plugin ruim ignorado/quarentenado, outros permanecem

Afirme:

• gateway atinge o estado pronto
• openclaw status --json inclui diagnósticos de plugins
• openclaw plugins inspect --all --json é analisável
• a árvore do pacote não é mutada
• logs não contêm tokens brutos

Representantes de Config Round-Trip

Use famílias de plugins representativas em vez de todos os plugins para round-trip profundo de config:

• provedores: openai, anthropic, mistral, openrouter
• canais: telegram, discord, slack, whatsapp
• memória: memory-lancedb
• feature/runtime: browser, acpx, tokenjuice

Para cada representante:

1. Escreva config através da CLI quando possível.
2. Leia-a de volta através de config get ou JSON.
3. Execute plugins inspect.
4. Execute doctor --non-interactive.
5. Acione o recarregamento de config do gateway, se aplicável.
6. Compare o hash da config antes e depois de comandos no-op.

Smoke SDK Externo

Em uma lane Docker de pacote, crie pequenos plugins externos e instale-os a partir de:

• diretório local
• .tgz
• especificação npm file:

Cubra formas CJS e ESM, além de pelo menos um plugin importando subcaminhos focados de openclaw/plugin-sdk/*. Afirme que plugins inspect vê sua ferramenta, método de gateway, comando CLI ou serviço.

Regras de Sondagem Live-Ish

Antes do trabalho live-ish, obtenha env permitido no Testbox e gere uma matriz de disponibilidade redigida: presente/ausente apenas, nunca valores.

Execute apenas sondagens para credenciais que existem. Prefira sondagens de auth/catálogo/status em vez de enviar mensagens visíveis ao usuário. Se uma sonda puder contatar um usuário externo, canal ou workspace, pare e pergunte ao usuário.

Relatório

Relate neste formato:

pacote/ref:
ids tbx / urls de execução:
matriz:
  ciclo de vida agrupado:
  package acceptance:
  doctor/fix:
  bootstrap do gateway:
  config round-trip:
  sdk externo:
  live-ish:
falhas:
pulos:
próxima lacuna de maior valor:

Diga claramente quando uma falha é dano de sincronização/env do Testbox em vez de comportamento do produto, e prove isso com uma reexecução limpa ou comparação com o main atual.