Prune docker images/volumes in free-disk-space script#19229
Conversation
Test suites pull many testcontainers images over the course of a single CI job (elasticsearch, kafka connect, etc.), which can exhaust runner disk space mid-run. Prune whatever shipped with the runner image first to make more room, following the same pattern as open-telemetry#15597 and open-telemetry#15851. Signed-off-by: Gregor Zeitlinger <[email protected]>
Pull request dashboard statusStatus last refreshed: 2026-07-26 21:34:55 UTC.
This automated status or its linked feedback items may be incorrect. If something looks wrong, please report it with the result you expected. |
Probe Docker before pruning so Windows jobs with a stopped service can reach the existing service-start workaround. Keep actual prune failures fatal once the daemon responds. Observed in the existing PR run 29429470350 on ubuntu-24.04: Docker prune reported 1.851GB reclaimed from runner-image content. This is image-dependent and not a guaranteed amount; GitHub-hosted jobs use fresh runners, so prior workflow runs are not a source of Docker data. Signed-off-by: Gregor Zeitlinger <[email protected]>
|
A possible follow-up would be to prune Docker data during a long-running job, but only at safe boundaries between independent test batches or when disk pressure crosses a threshold—not concurrently with active Testcontainers workloads. That would need separate measurement: reclaimed space, prune duration, image re-pulls, total job time, and whether it prevents |
Summary
No space left on deviceon atest3matrix job, disk went from 39GB free to 0 during the test run).docker system prune -af --volumesto.github/scripts/gha-free-disk-space.sh, removing unused Docker content already present on the runner before tests begin.Caveat: this only frees space before tests start, matching the existing script's approach — it does not address images pulled during the job, so it may reduce but not eliminate this failure mode.
Observed evidence
Test plan