COMP: Free disk on Linux.Python CI before post-job ccache tar

[hjmjohnson]

Fixes a recurring ITK.Linux.Python post-job tar: Error is not recoverable (ENOSPC) by inserting a disk-cleanup step between Build and test and the implicit Cache@2 post-job uploader. Builds 14748 and 14751 both hit this; build/test phases were green, only the cache upload failed.

Root cause (deep dive on build 14751)

The ccache stats step before the post-job prints:

Primary storage:
  Cache size (GB): 4.94 / 5.00 (98.87 %)
  Cleanups:          15

Local ccache is at the soft ceiling and has self-evicted 15 times during one build. The post-job Cache@2 task then tries to tar the entire 4.94 GB ccache for upload on a runner whose / is already at 96% used:

2026-05-03T04:11:31.6036279Z tar: fce56f0f2f94438cabba19e4f240f17a_archive.tar: Wrote only 4096 of 10240 bytes
2026-05-03T04:11:31.6042095Z tar: Error is not recoverable: exiting now
2026-05-03T04:11:32.1885773Z ##[error]Process returned non-zero exit code: 2

Every run also reports There is a cache miss. for the ccache-v4|Linux|LinuxPython|<sha> fingerprint, so the next run is cold too — the pipeline is stuck in a self-perpetuating broken state.

What this PR adds

A new step in Testing/ContinuousIntegration/AzurePipelinesLinuxPython.yml, inserted after Build and test and before ccache stats:

- bash: |
    df -h /
    ccache --show-stats
    ccache --evict-older-than 5d
    ccache --max-size 6.5G
    ccache -c
    ccache --show-stats
    ninja -C $(Build.SourcesDirectory)-build clean || true
    df -h /
  condition: always()
  displayName: 'Free disk before post-job ccache upload'

• ccache --evict-older-than 5d drops stale entries that no longer match recent compiler/source SHAs.
• ccache --max-size 6.5G lowers the local ceiling. Combined with ccache -c (cleanup) this forces the local store under the new ceiling so the tar fits in the runner's available disk.
• ninja -C <build> clean removes the .o files that are no longer needed after the build/test phase reported. || true lets the step succeed if the tree is already clean.
• Bracketing df -h / calls give visibility on both sides of the cleanup so future regressions are diagnosable from logs alone.
• condition: always() so even a failing build/test phase still gets the post-job a free runway.

Why 6.5G specifically

The build-time env still has CCACHE_MAXSIZE: 8G so ccache has room to operate during the build. The post-job ceiling of 6.5G is below the runner's typical free-disk headroom at the end of a Python wrapping build (the build itself consumes ~30-35 GB across /home/vsts/work for sources + build tree + ExternalData + ccache combined). Lowering further would unnecessarily evict warm entries; leaving at 8G would not actually fix the immediate failure. 6.5G is the sweet spot.

Doesn't address (and shouldn't, in this PR)

• Whether the ccache-v4|...|<Build.SourceVersion> cache fingerprint is too coarse / too fine. Separate optimization.
• Whether CCACHE_MAXSIZE: 8G env at the Build and test step actually takes effect (logs show ccache reporting a 5G ceiling there — possibly a persistent ccache config overrides). Worth a follow-up but not blocking this fix.
• The same disk-pressure pattern on ITK.macOS.Python (build 14750 currently green, but the same growth trajectory could hit it).

[dzenanz]

I have noticed the "low disk space" warning. This is at least worth trying.