Modelo de almacenamiento
Mantis utiliza tres capas de almacenamiento:- Imagen del proveedor - propiedad de Crabbox, almacenada en la cuenta del proveedor de nube. Contiene las capacidades de la máquina (Chrome/Chromium, ffmpeg, scrot, Node/corepack/pnpm, herramientas de compilación nativas) y directorios de caché vacíos.
- Estado del arrendamiento activo - propiedad de la sesión actual del operador. Puede contener un
perfil de navegador con sesión iniciada,
/var/cache/crabbox/pnpmy un checkout del código fuente preparado mientras el arrendamiento esté activo. - Artefactos de Mantis - propiedad de la ejecución de OpenClaw. Se encuentran en
.artifacts/qa-e2e/mantis/...; GitHub Actions los carga y la aplicación de GitHub de Mantis publica comentarios con evidencia en línea en el PR.
node_modules ni dist/ en una imagen del proveedor.
Despacho de GitHub
Ejecute el flujo de trabajo desdemain:
candidate_ref está restringido porque el flujo de trabajo utiliza credenciales reales: debe
resolverse como parte de la ascendencia actual de main, una etiqueta de versión o la cabecera de un PR abierto en
openclaw/openclaw.
El flujo de trabajo produce:
- artefacto cargado
mantis-slack-desktop-smoke-<run-id>-<attempt> - comentario en línea en el PR de la aplicación de GitHub de Mantis
slack-desktop-smoke.png,slack-desktop-smoke.mp4slack-desktop-smoke-preview.gif,slack-desktop-smoke-change.mp4mantis-slack-desktop-smoke-summary.json,mantis-slack-desktop-smoke-report.md- registros remotos:
slack-desktop-command.log,openclaw-gateway.log,chrome.log,ffmpeg.log
<!-- mantis-slack-desktop-smoke -->.
CLI local
Prueba en frío desde el código fuente:--hydrate-mode prehydrated solo cuando el espacio de trabajo remoto reutilizado ya
tenga node_modules y un dist/ compilado; de lo contrario, Mantis se cierra de forma segura.
Demuestre la interfaz nativa de aprobación de Slack:
--approval-checkpoints es mutuamente excluyente con --gateway-setup. Ejecuta
los escenarios opcionales slack-approval-exec-native y slack-approval-plugin-native,
a menos que se proporcione un --scenario explícito de punto de control de aprobación; los demás
escenarios de Slack se rechazan antes de que se inicie la máquina virtual. El ejecutor de QA de Slack escribe
cada archivo JSON de punto de control a partir del mensaje real de la API de Slack que observó y, a continuación,
el observador remoto representa ese mensaje en
approval-checkpoints/<scenario>-pending.png y
approval-checkpoints/<scenario>-resolved.png. La ejecución falla si falta o está vacío algún
JSON de punto de control, evidencia del mensaje, JSON de confirmación o captura de pantalla representada.
Los arrendamientos en frío de GitHub Actions no contienen cookies de Slack Web, por lo que la captura del navegador
puede mostrar la pantalla de inicio de sesión de Slack. Para la prueba de puntos de control de aprobación, confíe en las
imágenes representadas de los puntos de control y en los artefactos de QA de Slack en lugar de
slack-desktop-smoke.png. Utilice únicamente un arrendamiento activo conservado con un perfil
de Slack Web en el que se haya iniciado sesión manualmente cuando la propia captura de pantalla del navegador deba mostrar
Slack Web.
Modos de hidratación
GitHub Actions siempre prepara el checkout candidato antes de la ejecución de la máquina virtual. Su
almacén de pnpm se almacena en caché según el sistema operativo, la versión de Node y el archivo de bloqueo. La ejecución de
source en la máquina virtual
también reutiliza /var/cache/crabbox/pnpm cuando está presente.
Interpretación de los tiempos
mantis-slack-desktop-smoke-report.md incluye los tiempos de las fases:
crabbox.warmup- arranque del proveedor de nube, disponibilidad del escritorio/navegador y SSH.crabbox.inspect- consulta de los metadatos del arrendamiento.credentials.prepare- adquisición del arrendamiento de credenciales de Convex.crabbox.remote_run- sincronización, inicio del navegador, instalación/compilación de OpenClaw o validación de la hidratación, inicio del Gateway, captura de pantalla y grabación de vídeo.artifacts.copy- rsync de vuelta desde la máquina virtual.
crabbox.remote_run puede mostrar accepted cuando Crabbox devuelve un estado remoto distinto de cero,
pero Mantis copió metadatos que demuestran que se completó la configuración del Gateway de OpenClaw
o que el propio comando de QA de Slack terminó correctamente. Considere
accepted como una ejecución aprobada con explicación, no como un escenario fallido.
Si una ejecución es lenta:
- Predomina el calentamiento: precompile o promueva una imagen mejor del proveedor de Crabbox.
- Predomina
remote_runensource: utilice un arrendamiento activo, mejore la reutilización del almacén de pnpm o traslade los prerrequisitos de la máquina a la imagen del proveedor. - Predomina
remote_runenprehydrated: el espacio de trabajo remoto no estaba realmente preparado, o la configuración del Gateway, el navegador o Slack es lenta. - Predomina la copia de artefactos: examine el tamaño del vídeo y el contenido del directorio de artefactos.
Lista de comprobación de evidencias
Un buen comentario de PR muestra:- identificador del escenario y SHA candidato
- URL de la ejecución de GitHub Actions y URL del artefacto
- captura de pantalla en línea del punto de control de aprobación o una captura de Slack Web desde un arrendamiento activo con sesión iniciada
- vista previa animada en línea cuando esté disponible
- enlaces al MP4 completo y al MP4 recortado
- estado de aprobación/error y resumen de tiempos del informe
Gestión de errores
Si el flujo de trabajo falla antes de la ejecución de la máquina virtual, examine primero el trabajo de Actions. Las causas habituales son uncandidate_ref no confiable, secretos de entorno ausentes o un
error de instalación/compilación del candidato.
Si la ejecución de la máquina virtual falla pero se copiaron las capturas de pantalla, examine:
crabbox vnc ...
del informe y, a continuación, detenga el arrendamiento cuando termine:
--lease-id. No incluya ese perfil del navegador en una imagen del proveedor.