ci(standards-build): build jouleclaw-rs on linux-arm64 without debuginfo #95

Merged

dcharlot merged 1 commit from ci/jouleclaw-arm64-debuginfo into main 2026-09-17 21:07:36 -04:00

Conversation 0 Commits 1 Files changed 1 +21 -3

dcharlot commented 2026-09-17 07:20:15 -04:00

Owner

Copy link

What

The standards-build / build + test (jouleclaw-rs) leg on linux-arm64 has been failing on main. The cause is disk space, not the code: the link step fails with No space left on device.

This PR builds that one job with CARGO_PROFILE_DEV_DEBUG=0.

Why it fails

• Linux embeds full DWARF in every test binary, so jouleclaw-rs's aarch64 test target is very large with default debuginfo.
• Job containers and /ci-cache both live on the txarm VM's 118 GB volume (/dev/vdb1), which is 87% used, ~15 GB free. The build runs past that free space.
• The runner has capacity: 1, so no other job competes for the space. The one build alone doesn't fit.

Evidence

I reproduced the build on the txarm VM with the same toolchain, -C target-feature=+fp16 and container image:

debuginfo	result
default (debug = true)	out of space at link
CARGO_PROFILE_DEV_DEBUG=0	target ≈ 6.2 GB, 4471 tests pass

This PR's own CI run on the real runner is the final check.

Scope

• Only the jouleclaw-rs job changes. It is set through $GITHUB_ENV in a step gated on matrix.name. A matrix-level env field would give every other job an empty CARGO_PROFILE_DEV_DEBUG.
• A cache_suffix: "-nodebug" gives this job a fresh cache namespace, so it can't restore the old full-debuginfo target alongside the new build. For every other matrix entry the suffix is empty and the cache key string is unchanged.
• Panic messages keep file:line, which comes from the panic location, not DWARF. The only loss is symbolised backtraces in this one CI leg.

Not fixed here

The volume is still 87% full, mostly other workspaces' caches. This PR brings jouleclaw-rs back under the limit. It does not free up space for the other linux-arm64 jobs.

🤖 Generated with Claude Code

## What The `standards-build / build + test (jouleclaw-rs)` leg on `linux-arm64` has been failing on `main`. The cause is disk space, not the code: the link step fails with `No space left on device`. This PR builds that one job with `CARGO_PROFILE_DEV_DEBUG=0`. ## Why it fails - Linux embeds full DWARF in every test binary, so jouleclaw-rs's aarch64 test target is very large with default debuginfo. - Job containers and `/ci-cache` both live on the txarm VM's 118 GB volume (`/dev/vdb1`), which is **87% used, ~15 GB free**. The build runs past that free space. - The runner has `capacity: 1`, so no other job competes for the space. The one build alone doesn't fit. ## Evidence I reproduced the build on the txarm VM with the same toolchain, `-C target-feature=+fp16` and container image: | debuginfo | result | |---|---| | default (`debug = true`) | out of space at link | | `CARGO_PROFILE_DEV_DEBUG=0` | target ≈ 6.2 GB, **4471 tests pass** | This PR's own CI run on the real runner is the final check. ## Scope - **Only the jouleclaw-rs job changes.** It is set through `$GITHUB_ENV` in a step gated on `matrix.name`. A matrix-level env field would give every other job an empty `CARGO_PROFILE_DEV_DEBUG`. - A `cache_suffix: "-nodebug"` gives this job a fresh cache namespace, so it can't restore the old full-debuginfo target alongside the new build. For every other matrix entry the suffix is empty and the cache key string is unchanged. - Panic messages keep `file:line`, which comes from the panic location, not DWARF. The only loss is symbolised backtraces in this one CI leg. ## Not fixed here The volume is still 87% full, mostly other workspaces' caches. This PR brings jouleclaw-rs back under the limit. It does not free up space for the other `linux-arm64` jobs. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

dcharlot added 1 commit 2026-09-17 07:20:15 -04:00

ci(standards-build): build jouleclaw-rs on linux-arm64 without debuginfo ... 6548cf9358

The jouleclaw-rs leg on linux-arm64 has been red on main because its
aarch64 test target, with Linux's full DWARF embedded in every test
binary, outgrows the ~15 GB left on the shared txarm volume
(/var/lib/docker and /ci-cache are both on /dev/vdb1, 87% used). The
link fails with "No space left on device" — a capacity failure, not a
code failure.

Reproduced with the same toolchain, +fp16 rustflags and image: with
debuginfo the build runs out of space at link; with
CARGO_PROFILE_DEV_DEBUG=0 the target is ~6 GB and the full suite passes.

Scoped to this one job via $GITHUB_ENV (a matrix-level env field would
give every other job an empty CARGO_PROFILE_DEV_DEBUG). A cache_suffix
moves this job to a fresh cache namespace so it cannot restore the old
full-debuginfo target alongside the new build; every other job's cache
key string is unchanged.

Co-Authored-By: Claude Opus 5 <[email protected]>

dcharlot merged commit 5a08161056 into main 2026-09-17 21:07:36 -04:00

dcharlot referenced this pull request from a commit 2026-09-17 21:07:38 -04:00

ci(standards-build): build jouleclaw-rs on linux-arm64 without debuginfo (#95)

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

Transaction-Science/open-standards!95

No description provided.