[CI][UBTI] Free disk space first

[teqdruid]

The GH runners are severely disk space limited. Clean up a bunch of stuff which we don't need before we do anything else.

[Copilot]

Pull request overview

This PR updates the Unified Build/Test/Install GitHub Actions workflow to proactively reclaim disk space on Linux GitHub-hosted runners before checking out and building CIRCT, addressing recurring “out of space” CI failures.

Changes:

• Adds an early “Free disk space” step on Linux runners using jlumbroso/free-disk-space.
• Configures the cleanup to remove Android/.NET/Haskell components and Docker images while leaving large packages and tool-cache intact.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[uenoku]

Could we skip this step for release builds? The doc mentions a 3-minute overhead, which we should probably avoid in our standard PR CI (which uses release builds). I suspect disk space isn't as constrained during release builds anyway

https://github.com/jlumbroso/free-disk-space

this can clear up to 31 GB of disk space in about 3 minutes (the longest period is calling apt to uninstall packages)

The step finished less than a minute (maybe because large-packages: false) so it looks fine to always run this.

[teqdruid]

Here's another clue as to why our builds are failing sporadically: sometimes the runners have 145GB disks and other times it's 72GB.

@uenoku the most time I've seen it take is 1m43s. The other one is ~45s. I'd say that overhead is worth it so we're not (in the future) wondering why release works but not debug. (I've been bitten by this sort of environment divergence in the past.)

[teqdruid]

Nightly test matrix: https://github.com/llvm/circt/actions/runs/25879925419

Removing all but large-packages gets us an additional 25GB.

[circt-bot]

Results of circt-tests run for 1821841 compared to results for 20e590b: no change to test results.

[teqdruid]

WTF!

https://github.com/llvm/circt/actions/runs/25879925419/job/76056891061#step:20:6291

We gave this build an extra 25 GB of space and it still doesn't have enough space for static linking. Is this an actual bug?

[seldridge]

@teqdruid: Hey, this looks great!

If it's just the link, we really should not be using ld as it is known to be bad for LLVM generally. Maybe we can switch to lld or mold when using gcc for linking. I know people have had problems with gcc + ld just on normal desktops/servers.

[seldridge]

@teqdruid wrote:

Here's another clue as to why our builds are failing sporadically: sometimes the runners have 145GB disks and other times it's 72GB.

This is also great info. Thanks for figuring this out. I had suspected that there was some variability here, but hadn't suspected it was that much! Nice find.

[uenoku]

FWIW the static + Debug used 50GB locally,

du -ah build_debug | sort -rh | head -n 20
49G	build_debug
23G	build_debug/bin
16G	build_debug/lib
9.2G	build_debug/tools
5.0G	build_debug/tools/circt
4.2G	build_debug/tools/mlir
4.0G	build_debug/tools/mlir/lib
3.1G	build_debug/tools/mlir/lib/Dialect
2.5G	build_debug/tools/circt/lib
2.4G	build_debug/tools/circt/unittests
2.3G	build_debug/bin/arcilator
2.2G	build_debug/bin/circt-lec
2.2G	build_debug/bin/circt-bmc
2.0G	build_debug/tools/circt/unittests/Dialect
1.9G	build_debug/tools/circt/lib/Dialect
1.8G	build_debug/bin/circt-opt
1.2G	build_debug/lib/Transforms
1.2G	build_debug/bin/circt-translate
1.1G	build_debug/bin/circt-test
1023M	build_debug/lib/CodeGen