Stockage et auto-maintenance : pourquoi le disque ne se remplit pas
Une suite qui exécute des milliers de tests par jour génère des preuves en continu : vidéos, traces, captures d'écran et rapports. Nexus Studio régule cela de manière autonome. Chaque dossier dispose d'un plafond par test, l'ensemble des preuves partage un budget unique, et le disque préserve un seuil minimal d'espace libre. Cette page explique ce qui s'accumule, ce qui est purgé en premier, ce qui n'est jamais supprimé, et ce que représentent 10 000 exécutions par jour sur le disque.
Par l'équipe Nexus Studio, Verdict System LLC. 9 octobre 2026.
Ce qui s'accumule et pourquoi cela reste sous contrôle
Chaque exécution enregistre des données. Un succès conserve une capture d'écran et ses métadonnées. Un échec conserve un dossier : report.md, metadata.json, raw-data.json, screenshot.png et, en cas d'échec avéré, video.webm et trace.zip. Les exécutions API, chaos, Smart Monkey, de charge et de régression visuelle conservent leurs propres dossiers, et chaque exécution ajoute une entrée à l'Historique ainsi que des fichiers temporaires au cache d'exécution.
Un plafond par test ne suffit pas à lui seul. Conserver 20 exécutions en échec représente peu pour un seul test, mais sature un disque pour 10 000 tests. C'est pourquoi le moteur régule le stockage sur deux niveaux : un plafond par test, et un budget global pour l'ensemble des preuves qui n'augmente pas avec le nombre de tests.
Premier niveau : un plafond par test
Chaque type de preuve conserve un nombre déterminé d'exécutions, les plus récentes. Voici les valeurs par défaut :
| Preuves | Conservé par défaut | Paramètre |
|---|---|---|
| Échecs | Les 20 exécutions les plus récentes par test et navigateur | NEXUS_BUGREPORT_RETAIN |
| Succès | Les 5 exécutions les plus récentes par test et navigateur | NEXUS_PASSED_RETAIN |
| Exécutions d'API | Les 20 exécutions réussies les plus récentes par test d'API. Les échecs n'ont pas de limite propre : le budget les plafonne. | NEXUS_API_EVIDENCE_KEEP |
| Exécutions en mode chaos | Les 20 exécutions conservées les plus récentes par test et navigateur. Les exécutions interrompues n'ont pas de limite propre : le budget les plafonne. | NEXUS_CHAOS_RETAIN |
| Régressions visuelles | Les 10 plus récentes par test et point de contrôle | NEXUS_VISUAL_REGRESSION_RETAIN |
| Sessions Smart Monkey | Les 10 plus récentes | NEXUS_MONKEY_RETAIN |
| Contexte d'exécution | Les 100 exécutions les plus récentes | NEXUS_RUN_CONTEXT_RETAIN |
| History | Les 50 lignes les plus récentes par test et navigateur | NEXUS_HISTORY_RETAIN |
| Archive de télémétrie | Au maximum 2 fichiers zip, aucun datant de plus de 7 jours, 500 Mo au total | NEXUS_CACHE_ZIPS, NEXUS_CACHE_RETENTION_DAYS, NEXUS_CACHE_MAX_MB |
Chacune d'entre elles correspond à une ligne dans le fichier .env de l'espace de travail. Les paramètres les modifient toutes, à l'exception des trois limites de télémétrie.
Deuxième niveau : un budget unique pour toutes les preuves, et un seuil d'espace libre
NEXUS_EVIDENCE_MAX_GB, défini par défaut à 20 Go, limite l'ensemble des preuves : échecs, succès, API, chaos, Smart Monkey, tests de charge et de régression visuelle. Cette limite n'augmente pas avec le nombre de tests. Que vous ayez 100 tests ou 10 000, le volume des preuves reste en dessous.
NEXUS_MIN_FREE_GB, défini par défaut à 10 Go, correspond à l'espace libre conservé sur le disque. Lorsque le disque descend sous ce seuil, les preuves les plus anciennes sont supprimées, même si le total reste inférieur au budget alloué.
Lorsque l'une ou l'autre de ces limites est franchie, le moteur supprime des dossiers d'exécution entiers, dans cet ordre :
- Les exécutions réussies et les régressions visuelles, les plus anciennes d'abord.
- Puis les échecs, les plus anciens d'abord.
- Il s'arrête dès que le volume des preuves repasse sous le budget et que l'espace disque repasse au-dessus de son seuil minimal.
S'il ne reste que l'exécution la plus récente de chaque test et que le total dépasse toujours le budget, le moteur vous le signale à la fin de l'exécution : augmentez le budget, ou archivez ce dont vous avez besoin et libérez les exécutions plus anciennes. Le seuil minimal ne concerne que les preuves. Lorsque d'autres fichiers remplissent le disque, le moteur libère ses propres preuves jusqu'à ne conserver que l'exécution la plus récente de chaque test, et le Studio continue de vous avertir que l'espace disque est faible.
Ce qui n'est jamais supprimé
- L'exécution la plus récente de chaque test et navigateur, ainsi que la session Smart Monkey et le test de charge les plus récents. L'exécution qui vient de se terminer est toujours la plus récente de sa catégorie.
- Archive. Les copies que vous avez choisi de conserver avec Archive… dans l'Evidence Locker se trouvent à côté du dossier des preuves, et non à l'intérieur. Ni les plafonds ni le budget ne les affectent.
- Historique. La suppression d'un dossier d'exécution ne supprime pas la ligne correspondante. L'historique conserve sa propre fenêtre, définie par défaut à 50 exécutions par test et par navigateur.
- La chaîne de traçabilité. Le registre fonctionne uniquement en ajout et n'est jamais tronqué.
Les preuves scellées sont purgées de manière consignée
Le scellement est optionnel. Un enregistrement scellé hache chaque fichier de son dossier avec SHA-256 et le lie à l'enregistrement précédent ; ainsi, un dossier scellé qui disparaîtrait sans trace ressemblerait exactement à une altération frauduleuse.
Avant que le budget ne supprime un dossier scellé, le moteur ajoute une entrée PURGE à son sujet dans le registre, indiquant que le budget disque en est à l'origine ainsi que la date et l'heure. Le registre prouve toujours la valeur de hachage du dossier, et nexus verify signale l'enregistrement comme PURGED, et non comme altéré. Si le registre ne peut pas enregistrer la mention PURGE, le dossier est conservé.
Ce qui s'exécute automatiquement, et quand
Le moteur assure sa propre maintenance après chaque exécution, quel que soit le mode : un test unique, une suite, une boucle, une planification Watch, Selenium, pytest et les exécutions d'API.
- L'espace libre est vérifié après chaque exécution.
- Les preuves sont évaluées au maximum toutes les 15 minutes, ou immédiatement lorsque l'espace disque passe sous son seuil minimal. Cette passe supprime les exécutions les plus anciennes jusqu'à ce que les deux limites soient respectées.
- Les fichiers temporaires sont nettoyés. Les fichiers de résultats par exécution et les journaux de l'application testée sont supprimés dès qu'ils ont plus de 24 heures. Les journaux d'erreurs de configuration ne conservent que les 14 fichiers les plus récents. Les dossiers laissés par une exécution interrompue dans le dossier temporaire de Windows sont également supprimés au bout de 24 heures.
- Le dossier de sortie temporaire de Playwright est vidé au début et à la fin de chaque exécution.
- Les journaux effectuent une rotation à 10 Mo.
- Les fichiers temporaires de télémétrie sont compressés dans un fichier zip après chaque exécution, dans le respect des trois limites ci-dessus.
Ce que vous voyez dans le Studio
Espace de travail › Disque affiche :
- les preuves utilisées par rapport au budget ;
- l'espace disque libre par rapport au seuil minimal ;
- la date et l'heure de la dernière vérification, ainsi que l'espace libéré lors de la dernière passe ;
- Exécuter la maintenance maintenant, qui lance immédiatement la même passe au lieu d'attendre la prochaine exécution.
Lorsque l'espace libre passe sous le seuil minimal, le Studio affiche un avertissement d'espace disque faible. Les deux limites se trouvent dans Paramètres, sous Preuves & Rétention. Ce même panneau répertorie chaque dossier dans lequel une exécution écrit, avec sa taille et sa limite : ce que chaque exécution conserve.
Docker et hôtes distants
Le moteur peut exécuter des suites dans Docker sur cette machine ou dans un conteneur sur un serveur Linux via SSH. Le Studio lui-même reste sous Windows.
- Les journaux de conteneurs sont limités à trois fichiers de 10 Mo par service, de sorte qu'un conteneur qui s'exécute pendant des mois n'encombre pas l'hôte avec ses propres sorties.
- Le runner GitHub auto-hébergé s'enregistre une seule fois. Un redémarrage réutilise son enregistrement au lieu de s'enregistrer à nouveau.
- Le moteur sur cet hôte est le même moteur, avec les mêmes limites, le même budget et le même seuil plancher pour les preuves qu'il y écrit.
Un exemple concret : 10 000 exécutions par jour
Il s'agit d'une estimation, pas d'une mesure. Supposons :
- 10 000 exécutions de tests par jour ;
- 5 % d'échecs, soit 500 échecs par jour ;
- environ 3 Mo par dossier d'échec : vidéo, trace, capture d'écran et données.
Cela représente environ 1,5 Go de preuves d'échec par jour. Avec la valeur par défaut de 20 Go, environ les deux dernières semaines d'échecs restent sur le disque, et le total des preuves ne dépasse jamais 20 Go. Les réussites sont supprimées en premier, afin que l'espace soit alloué aux échecs, c'est-à-dire aux preuves dont vous avez le plus probablement besoin.
Les 3 Mo supposent que la vidéo et la trace soient toutes deux conservées. Le dossier BREACHED sur la page des preuves pèse 531,2 ko avant sa trace.
Ajustement pour les grandes suites
- Plus d'historique : augmentez
NEXUS_EVIDENCE_MAX_GB. Sur un disque de 1 To, un budget de 200 Go permet de conserver dix fois la valeur par défaut, soit environ quatre mois d'échecs à raison de 1,5 Go par jour. Les limites par test s'appliquent toujours : un test conserve au maximum ses 20 exécutions en échec, à moins que vous n'augmentiez égalementNEXUS_BUGREPORT_RETAIN. - Moins de volume par échec : désactivez la trace avec
NEXUS_TRACE_ENABLED=false, ou conservez la vidéo pour moins de verdicts avecNEXUS_VIDEO_VERDICTS. Le même budget couvre alors un nombre de jours supérieur. - De la place pour d'autres programmes : augmentez
NEXUS_MIN_FREE_GBsi la machine nécessite plus de 10 Go d'espace libre. - Tests exécutés plusieurs fois par jour : augmentez
NEXUS_HISTORY_RETAIN, par exemple à 500, afin que l'historique couvre plus que quelques jours. - Un échec que vous devez conserver : archivez-le depuis l'Evidence Locker avant qu'il n'expire.
Questions
Mon disque va-t-il se remplir si j'exécute 10 000 tests par jour ?
Pas avec ses preuves. Les preuves restent sous leur budget, 20 Go par défaut, quel que soit le nombre de tests que vous exécutez, et le moteur supprime les preuves les plus anciennes pour conserver 10 Go d'espace disque libre. Un plus grand nombre d'exécutions par jour signifie que l'historique des preuves remonte moins loin dans le temps, et non qu'elles prennent plus de place. Les fichiers extérieurs aux preuves, comme les images Docker ou vos propres espaces de travail, ne font pas partie du budget.
Le nettoyage supprime-t-il parfois un échec dont j'ai besoin ?
Cela peut arriver, une fois que l'échec est suffisamment ancien : au-delà du budget, les exécutions les plus anciennes sont supprimées, les réussites avant les échecs, et l'exécution la plus récente de chaque test et navigateur est toujours conservée. Pour conserver définitivement un échec, choisissez Archiver… dans l'Evidence Locker. La copie est placée en dehors du dossier de preuves, et ni les limites ni le budget ne la touchent.
Un enregistrement scellé sera-t-il considéré comme altéré après un nettoyage ?
Non. L'entrée PURGE est d'abord inscrite dans le grand livre, et nexus verify signale l'enregistrement comme PURGED.
Que se passe-t-il lorsque le disque est presque plein ?
En dessous du seuil minimal, 10 Go par défaut, le moteur évalue immédiatement les preuves au lieu d'attendre son passage de 15 minutes, supprime les preuves les plus anciennes même sous le budget, et le Studio affiche un avertissement de disque faible. Si d'autres fichiers occupent l'espace, il libère ce qu'il peut et continue d'émettre l'avertissement.
Dois-je faire quelque chose ?
Non. Il s'exécute après chaque exécution. Exécuter la maintenance maintenant, sous Workspace › Disque, le lance immédiatement.