Mantis Slack desktop QA è il percorso con UI reale per i bug di classe Slack che richiedono un desktop Linux, recupero VNC, Slack Web, un vero Gateway OpenClaw, screenshot, video e un commento di evidenza sulla PR. Usalo quando i test unitari o il percorso live Slack headless non possono dimostrare il bug.Documentation Index
Fetch the complete documentation index at: https://docs2.openclaw.ai/llms.txt
Use this file to discover all available pages before exploring further.
Modello di archiviazione
Mantis usa tre diversi livelli di archiviazione:- Immagine del provider: di proprietà di Crabbox e archiviata nell’account del provider cloud. Contiene capacità della macchina come Chrome/Chromium, ffmpeg, scrot, Node/corepack/pnpm, strumenti di build nativi e directory di cache vuote.
- Stato del lease caldo: di proprietà della sessione operatore corrente. Può contenere un
profilo browser autenticato,
/var/cache/crabbox/pnpme un checkout del sorgente preparato mentre il lease è attivo. - Artefatti Mantis: di proprietà dell’esecuzione OpenClaw. Si trovano sotto
.artifacts/qa-e2e/mantis/..., poi GitHub Actions li carica e la Mantis GitHub App commenta le evidenze inline sulla PR.
node_modules o dist/ in un’immagine provider precotta.
Dispatch GitHub
Esegui il workflow damain:
candidate_ref consentiti sono intenzionalmente limitati perché il workflow
usa credenziali live: ancestry dell’attuale main, tag di release o head di una PR aperta
da openclaw/openclaw.
Il workflow scrive:
- artefatto caricato:
mantis-slack-desktop-smoke-<run-id>-<attempt>; - commento inline sulla PR dalla Mantis GitHub App;
slack-desktop-smoke.png;slack-desktop-smoke.mp4;slack-desktop-smoke-preview.gif;slack-desktop-smoke-change.mp4;mantis-slack-desktop-smoke-summary.json;mantis-slack-desktop-smoke-report.md;- log remoti come
slack-desktop-command.log,openclaw-gateway.log,chrome.logeffmpeg.log.
<!-- mantis-slack-desktop-smoke -->.
CLI locale
Prova sorgente a freddo:--hydrate-mode prehydrated solo quando l’area di lavoro remota riutilizzata ha già
node_modules e una dist/ compilata. Mantis fallisce in modo chiuso se mancano.
Modalità di idratazione
| Modalità | Usala quando | Comportamento remoto | Compromesso |
|---|---|---|---|
source | Normale prova PR, macchine a freddo, CI | Esegue pnpm install --frozen-lockfile --prefer-offline e pnpm build dentro la VM | Più lenta, prova più forte del checkout sorgente |
prehydrated | Hai preparato intenzionalmente un lease riutilizzato | Richiede node_modules e dist/ esistenti; salta install/build | Veloce, ma valida solo per lease caldi controllati dall’operatore |
/var/cache/crabbox/pnpm quando presente.
Interpretazione dei tempi
mantis-slack-desktop-smoke-report.md include i tempi delle fasi:
crabbox.warmup: avvio del provider cloud, prontezza di desktop/browser e SSH.crabbox.inspect: ricerca dei metadati del lease.credentials.prepare: acquisizione del lease delle credenziali Convex.crabbox.remote_run: sincronizzazione, avvio del browser, install/build OpenClaw o convalida dell’idratazione, avvio del Gateway, screenshot e acquisizione video.artifacts.copy: rsync di ritorno dalla VM.
crabbox.remote_run può essere contrassegnato come accepted quando Crabbox restituisce uno
stato remoto diverso da zero dopo che Mantis ha copiato metadati che dimostrano che il Gateway OpenClaw
è attivo e la configurazione è stata completata. Tratta accepted come superato con spiegazione,
non come scenario fallito.
Se l’esecuzione è lenta:
- domina il warmup: precuoci o promuovi un’immagine provider Crabbox migliore;
- domina remote_run in
source: usa un lease caldo, migliora il riutilizzo dello store pnpm, oppure sposta i prerequisiti della macchina nell’immagine provider; - domina remote_run in
prehydrated: l’area di lavoro remota non era realmente pronta, oppure la configurazione di Gateway/browser/Slack è lenta; - domina la copia degli artefatti: ispeziona la dimensione del video e i contenuti della directory degli artefatti.
Checklist delle evidenze
Un buon commento sulla PR dovrebbe mostrare:- ID scenario e SHA candidato;
- URL dell’esecuzione GitHub Actions;
- URL dell’artefatto;
- screenshot inline;
- anteprima animata inline quando disponibile;
- link al MP4 completo e al MP4 tagliato;
- stato pass/fail;
- riepilogo dei tempi nel report allegato.
Gestione degli errori
Se il workflow fallisce prima dell’esecuzione della VM, ispeziona prima il job Actions. Le cause tipiche sonocandidate_ref non attendibile, segreti dell’ambiente mancanti o errore di install/build del candidato.
Se l’esecuzione della VM fallisce ma gli screenshot sono stati copiati indietro, ispeziona:
crabbox vnc ... del report.
Ferma il lease quando hai finito:
--lease-id. Non incorporare quel profilo browser in un’immagine provider.