find: Debug a Disk-Full Runner
find -size and -printf pinpoint the files eating a runner disk when a job fails with no space left.
A "no space left on device" failure is opaque until you see what is filling the disk. find turns it into a ranked list of offenders.
What it does
To debug disk pressure, find walks the file system selecting large files with -size and reporting their sizes so you can sort and act. Scoping the start path (a build or cache directory) keeps the walk fast and avoids permission noise on system paths.
Common usage
find / -type f -size +500M 2>/dev/null
find . -type f -printf '%s %p\n' | sort -rn | head -20
find ~/.cache -type f -size +100M -exec ls -lh {} +Options
| Pattern | What it does |
|---|---|
| -size +500M | Files larger than 500 mebibytes |
| 2>/dev/null | Drop permission-denied noise from system paths |
| -printf "%s %p\n" | sort -rn | List by size, largest first (GNU) |
| -exec ls -lh {} + | Show human-readable sizes for matches |
In CI
Start the search at the most likely culprit (the workspace, ~/.cache, /tmp, or the Docker layer dir) rather than / so it finishes quickly. The GNU -printf "%s %p\n" | sort -rn ranking is the fastest way to see the top offenders; on macOS runners use -exec du -h {} + and sort instead.
Common errors in CI
find / floods the log with "find: '/proc/...': Permission denied"; redirect with 2>/dev/null. -printf is GNU only, so the sort-by-size one-liner fails on BSD/macOS find with "unknown predicate '-printf'"; switch to -exec du -h {} + there. Searching / can itself be slow on a busy runner, so scope it.