- Enviado
- 14 de noviembre de 2026 a las 21:43 UTC
- Autor
- Kamo
- Commit
- 18b221a
Sin prune en ejecución, `docker rm` de un contenedor de trabajo CI terminado todavía tomó 15-100 s: espera a que pase un contenedor GC (leases.Delete -> gcScheduler.ScheduleAndWait), y cada pasada pasó ese tiempo en la fase de marca (getMarked/scanRoots) caminando una base de metadatos hinchada por el historial de compilación de BuildKit Que nunca fue recortado: moby_history tenía 2,694 arrendamientos y 18,701 blobs atrás hasta el último inicio acoplado (2026-09-28), ~8x todo lo demás. - builder.history: maxAge 48h, maxEntries 100. - builder.gc: reemplazar la política predeterminada de 4 reglas (regla # 0 limitada localmente contexts/cache mounts a 2.57 GiB, borrando la caché después de las compilaciones) con una Hard backstop: caché máxima de 80 GB, se elimina cuando hay menos de 40 GB libres Ejecute el archivo k1m1-docker-prune.sh en la ventana inactiva. Aplicar solo en una ventana de CI silenciosa: el reinicio de docker también detiene forgejo-runner.