From 56bdd457dd4c3520943ca67c5ab96d0bcd678c91 Mon Sep 17 00:00:00 2001 From: Duncan Tourolle Date: Wed, 26 Aug 2026 01:13:32 +0200 Subject: [PATCH] Stop the test build filling the runner's disk The desktop job died mid-link with LLVM reporting "IO failure on output stream", which reads like a compiler crash and is not one: underneath it is `No space left on device`. The runner ran out of disk while linking. Worth knowing what it was spending it on. `target/debug` was 24 GB against `target/release`'s 2.6 GB -- the test build is roughly ninety percent of the footprint -- and of that, 15 GB was debug info in `debug/deps` and 3.6 GB was incremental state. Neither buys anything here. Nothing attaches a debugger to a CI run, and incremental compilation exists to make the second build in a working tree fast, which is not a thing a fresh checkout ever has. With both off the same tree is 3.3 GB, `debug/deps` 2.8 GB, and the test binaries build unchanged. Backtraces keep function names and lose file and line numbers; if a failure ever needs those, DEBUG=1 gives line tables back for a fraction of the 15 GB. A `df -h` either side of the expensive steps, so the next time this happens it says so in one line rather than as an error from LLVM. This is a mitigation and it should not be mistaken for the fix. It bounds what this job asks for; it cannot help if the runner is full of anything else, and 24 GB of build output is not obviously the largest thing on a host that also keeps every cached target directory this workflow has ever saved. If it fails here again, the disk needs looking at on draco-x86. Co-Authored-By: Claude Opus 5 --- .gitea/workflows/build-and-test.yml | 34 +++++++++++++++++++++++++++++ 1 file changed, 34 insertions(+) diff --git a/.gitea/workflows/build-and-test.yml b/.gitea/workflows/build-and-test.yml index 8c8d17e..5031deb 100644 --- a/.gitea/workflows/build-and-test.yml +++ b/.gitea/workflows/build-and-test.yml @@ -27,6 +27,30 @@ jobs: container: image: catthehacker/ubuntu:act-latest + # This job filled the runner's disk and died mid-link with "No space left + # on device" — LLVM reporting an IO failure on its output stream, which + # reads like a compiler crash and is not one. + # + # `target/debug` was 24 GB against `target/release`'s 2.6 GB: 15 GB of it + # debug info in `debug/deps`, 3.6 GB incremental state. Neither earns its + # space here. Nothing attaches a debugger to a CI run, and incremental + # compilation exists to make the *second* build in a working tree fast, + # which is not a thing a fresh checkout has. Turning both off is the + # standard CI setting rather than a trick. + # + # Measured on this workspace: the same `cargo test --workspace --no-run` + # tree goes from 24 GB to 3.3 GB, `debug/deps` from 15 GB to 2.8 GB. + # + # Backtraces still name functions without debug info; they lose file and + # line numbers. If a test failure ever needs those, drop DEBUG to 1 + # (line-tables-only) rather than back to 2. + # + # This is a mitigation, not a fix. If the runner is full of anything other + # than this job's own output, it will still be full afterwards. + env: + CARGO_INCREMENTAL: 0 + CARGO_PROFILE_DEV_DEBUG: 0 + steps: - name: Checkout uses: actions/checkout@v4 @@ -101,6 +125,12 @@ jobs: --default-toolchain 1.92.0 --component rustfmt,clippy echo "$HOME/.cargo/bin" >> "$GITHUB_PATH" + # Free space before and after the expensive steps, so a repeat of the + # disk exhaustion above is one line to diagnose instead of a puzzling + # LLVM error. + - name: Disk before + run: df -h /workspace 2>/dev/null || df -h . + - name: Format run: cargo fmt --all -- --check @@ -116,6 +146,10 @@ jobs: - name: Build run: cargo build --workspace --release + - name: Disk after + if: always() + run: df -h /workspace 2>/dev/null || df -h . + android: runs-on: linux/amd64 name: Android (aarch64)