Almacenamiento y automantenimiento: por qué el disco no se llena

Una suite que corre miles de pruebas al día escribe evidencia todo el día: videos, traces, capturas de pantalla y reportes. Nexus Studio mantiene eso acotado por su cuenta. Cada carpeta tiene un tope por prueba, toda la evidencia junta tiene un solo presupuesto, y el disco conserva un piso de espacio libre. Esta página explica qué crece, qué se va primero, qué nunca se borra y cómo se ven en el disco 10,000 ejecuciones al día.

Por el equipo de Nexus Studio, Verdict System LLC. 9 de octubre de 2026.

Qué crece, y por qué se mantiene acotado

Cada ejecución escribe algo. Un aprobado conserva una captura de pantalla y sus metadatos. Una falla conserva una carpeta: report.md, metadata.json, raw-data.json, screenshot.png y, en una falla real, video.webm y trace.zip. Las ejecuciones de API, de caos, de Smart Monkey, de carga y de regresión visual conservan carpetas propias, y cada ejecución añade una fila a History y archivos temporales a la caché de ejecuciones.

Un tope por prueba no basta por sí solo. Conservar 20 ejecuciones fallidas es poco para una prueba y un disco lleno para 10,000 pruebas. Por eso el motor acota el almacenamiento en dos capas: un tope por prueba, y un solo presupuesto sobre toda la evidencia que no crece con el número de pruebas.

Capa uno: un tope por prueba

Cada tipo de evidencia conserva un número fijo de ejecuciones, las más recientes. Estos son los valores por defecto:

Cada uno es una línea del .env del espacio de trabajo. Settings los edita todos menos los tres límites de telemetría.

Capa dos: un solo presupuesto para toda la evidencia, y un piso de espacio libre

NEXUS_EVIDENCE_MAX_GB, 20 GB por defecto, acota toda la evidencia junta: fallas, aprobados y ejecuciones de API, de caos, de Smart Monkey, de carga y de regresión visual. No crece con el número de pruebas. Con 100 pruebas o con 10,000, la evidencia se queda por debajo.

NEXUS_MIN_FREE_GB, 10 GB por defecto, es el espacio libre que conserva el disco. Cuando el disco baja de ahí, la evidencia más vieja se va aunque el total siga por debajo del presupuesto.

Cuando se cruza cualquiera de los dos límites, el motor elimina carpetas de ejecución completas, en este orden:

1. Ejecuciones aprobadas y regresiones visuales, las más viejas primero.
2. Después las fallas, las más viejas primero.
3. Se detiene en cuanto la evidencia queda por debajo del presupuesto y el disco por encima de su piso.

Si solo queda la ejecución más reciente de cada prueba y el total sigue por encima del presupuesto, el motor lo dice al terminar la ejecución: sube el presupuesto, o archiva lo que necesitas y libera ejecuciones más viejas. El piso actúa solo sobre la evidencia. Cuando otros archivos llenan el disco, el motor libera su propia evidencia hasta dejar la ejecución más reciente de cada prueba, y el Studio sigue avisando que queda poco disco.

Lo que nunca se borra

• La ejecución más reciente de cada prueba y navegador, y la sesión de Smart Monkey y la ejecución de carga más recientes. La ejecución que acaba de terminar siempre es la más reciente de su grupo.
• Archive. Las copias que elegiste conservar con Archive… en el Evidence Locker quedan junto a la carpeta de evidencia, no dentro de ella. Ni los topes ni el presupuesto las alcanzan.
• History. Eliminar la carpeta de una ejecución no elimina su fila. History tiene su propia ventana, 50 ejecuciones por prueba y por navegador por defecto.
• La cadena de custodia. El ledger solo admite añadir y nunca se recorta.

La evidencia sellada se purga con constancia

El sellado es opcional. Un registro sellado calcula el hash SHA-256 de cada archivo de su carpeta y lo encadena al registro anterior, así que una carpeta sellada que desapareciera sin aviso se vería exactamente como una manipulación.

Antes de que el presupuesto elimine una carpeta sellada, el motor añade al ledger una entrada PURGE para ella, que nombra al presupuesto de disco como quien la eliminó y cuándo. El ledger sigue probando qué hash tenía la carpeta, y nexus verify informa el registro como PURGED, no como manipulado. Si el ledger no puede registrar el PURGE, la carpeta se queda.

Qué corre automáticamente, y cuándo

El motor se mantiene solo después de cada ejecución, en todos los modos: una prueba sola, una suite, un bucle, una programación de Watch, Selenium, pytest y ejecuciones de API.

• El espacio libre se revisa después de cada ejecución.
• La evidencia se pesa como máximo cada 15 minutos, o de inmediato cuando el disco está por debajo de su piso. Esa pasada elimina las ejecuciones más viejas hasta que se cumplen los dos límites.
• Los archivos temporales se barren. Los archivos de resultados de cada ejecución y los logs de la aplicación bajo prueba se van cuando tienen más de 24 horas. Los logs de errores de configuración conservan los 14 archivos más recientes. Las carpetas que una ejecución interrumpida dejó en la carpeta temporal de Windows también se van a las 24 horas.
• La carpeta temporal de salida de Playwright se vacía al empezar y al terminar cada ejecución.
• Los logs rotan a los 10 MB.
• Los archivos temporales de telemetría van a un zip después de cada ejecución, dentro de los tres límites de arriba.

Lo que ves en el Studio

Workspace › Disk muestra:

• la evidencia usada frente al presupuesto;
• el disco libre frente al piso;
• cuándo corrió la última revisión, y qué liberó la última pasada;
• Run maintenance now, que corre la misma pasada de inmediato en vez de después de la próxima ejecución.

Cuando el espacio libre baja del piso, el Studio muestra un aviso de disco bajo. Los dos límites están en Settings, en Evidence & Retention. El mismo panel lista cada carpeta en la que escribe una ejecución, con su tamaño y su límite: lo que conserva cada ejecución.

Docker y hosts remotos

El motor puede correr suites en Docker en esta máquina o en un contenedor en un servidor Linux por SSH. El Studio en sí se queda en Windows.

• Los logs de los contenedores tienen un tope de tres archivos de 10 MB por servicio, así que un contenedor que corre durante meses no llena el host con su propia salida.
• El runner autoalojado de GitHub se registra una sola vez. Un reinicio reutiliza su registro en vez de registrarse de nuevo.
• El motor en ese host es el mismo motor, con los mismos topes, presupuesto y piso para la evidencia que escribe allí.

Un ejemplo resuelto: 10,000 ejecuciones al día

Esto es una estimación, no una medición. Supón:

• 10,000 ejecuciones de prueba al día;
• falla el 5%, o sea 500 fallas al día;
• unos 3 MB por carpeta de falla: video, trace, captura de pantalla y datos.

Eso es alrededor de 1.5 GB de evidencia de fallas al día. Con el valor por defecto de 20 GB, quedan en el disco aproximadamente las últimas dos semanas de fallas, y la evidencia total nunca pasa de 20 GB. Los aprobados se van primero, así que el espacio queda para las fallas, la evidencia que más probablemente vas a necesitar.

Los 3 MB suponen que se conservan tanto el video como el trace. La carpeta BREACHED de la página de evidencia pesa 531.2 kB antes de su trace.

Ajustes para suites grandes

• Más historia: sube NEXUS_EVIDENCE_MAX_GB. En un disco de 1 TB, un presupuesto de 200 GB conserva diez veces lo que conserva el valor por defecto, unos cuatro meses de fallas a 1.5 GB al día. Los topes por prueba siguen aplicando: una prueba conserva como máximo sus 20 ejecuciones fallidas, salvo que también subas NEXUS_BUGREPORT_RETAIN.
• Menos por falla: apaga el trace con NEXUS_TRACE_ENABLED=false, o conserva el video de menos veredictos con NEXUS_VIDEO_VERDICTS. El mismo presupuesto alcanza entonces para más días.
• Espacio para otros programas: sube NEXUS_MIN_FREE_GB si la máquina necesita más de 10 GB libres.
• Pruebas que corren muchas veces al día: sube NEXUS_HISTORY_RETAIN, por ejemplo a 500, para que History cubra más de unos pocos días.
• Una falla que debes conservar: archívala desde el Evidence Locker antes de que envejezca y salga.

Preguntas

¿Va a llenar mi disco si corro 10,000 pruebas al día?

No con su evidencia. La evidencia se queda bajo su presupuesto, 20 GB por defecto, sin importar cuántas pruebas corras, y el motor elimina evidencia más vieja para mantener 10 GB del disco libres. Más ejecuciones al día significa que la evidencia llega menos atrás en el tiempo, no que ocupe más espacio. Los archivos fuera de la evidencia, como las imágenes de Docker o tus propios espacios de trabajo, no forman parte del presupuesto.

¿La limpieza puede borrar una falla que necesito?

Puede, cuando la falla ya es lo bastante vieja: pasado el presupuesto, se van las ejecuciones más viejas, los aprobados antes que las fallas, y la ejecución más reciente de cada prueba y navegador siempre se queda. Para conservar una falla para siempre, elige Archive… en el Evidence Locker. La copia queda fuera de la carpeta de evidencia, y ni los topes ni el presupuesto la tocan.

¿Un registro sellado aparece como manipulado después de la limpieza?

No. La entrada PURGE entra primero al ledger, y nexus verify informa el registro como PURGED.

¿Qué pasa cuando el disco está casi lleno?

Por debajo del piso, 10 GB por defecto, el motor pesa la evidencia de inmediato en vez de esperar su pasada de 15 minutos, elimina evidencia más vieja aunque esté bajo el presupuesto, y el Studio muestra un aviso de disco bajo. Si otros archivos ocupan el espacio, libera lo que puede y sigue avisando.

¿Tengo que hacer algo?

No. Corre después de cada ejecución. Run maintenance now, en Workspace › Disk, lo corre de inmediato.