- Expédié
- 14 novembre 2026 à 21:43 UTC
- Auteur
- Kamo
- Commit
- 18b221a
Sans prune en cours d'exécution, `docker rm` d'un conteneur de travail CI terminé a toujours pris 15-100 s: il attend un passage de GC de conteneur (leases.Delete -> gcScheduler.ScheduleAndWait), et chaque passage a passé ce temps dans la phase de marquage (getMarked/scanRoots) marcher sur une base de métadonnées gonflée par l'historique de compilation de BuildKit qui n'a jamais été coupé: moby_history détenait 2 694 baux et 18 701 blobs en arrière jusqu'au dernier démarrage (2026-09-28), ~8x tout le reste. - builder.history: maxAge 48h, maxEntries 100. - builder.gc: remplacer la politique par défaut à 4 règles (règle #0 plafonnée localement) contexts/cache mounts à 2,57 GiB, suppression du cache après les compilations) avec un Hard backstop: cache de 80 Go maximum, élagage lorsque < 40 Go libres La fenêtre d'inactivité k1m1-docker-prune.sh Appliquer uniquement dans une fenêtre CI silencieuse : le redémarrage de docker arrête également forgejo-runner.