Repository navigation
Build robustness: surface build output, ERR-trap friendly failures, -j resource guard #9
Description
Problem
cmake … &> /dev/null and make -j$CORES &> /dev/null (rigforge.sh:246-249) swallow all build output, so a failed compile aborts under set -e with zero diagnostics. There's also no ERR trap (pithead has on_err naming the step), and make -j$(nproc) can OOM the heavy XMRig build on low-RAM boxes.
Proposed
- Tee build output to a logfile (and/or don't suppress it); on failure point the user at it.
- Add a
trap … ERRthat names the failed step (mirror pithead'son_err). - Cap build parallelism on low-RAM hosts (reserve headroom).
Acceptance
- Build failures show actionable output / a logfile path.
- An ERR trap reports which step failed.
-
-jis bounded on low-memory machines.
Activity
VijitSingh97 commentedon Jun 6, 2026
#26 (closes #5) doesn't tackle the build-output / ERR-trap /
-jitems here, but two robustness-adjacent things from it are relevant:rigforge.shaborted underset -uin clean container/cron/CI environments becauseREAL_USER="${SUDO_USER:-$USER}"referenced an unsetUSER— now falls back toid -un. (Surfaced by the new Ubuntu E2E; the macOS suite missed it because Mac shells exportUSER.)/etc/logrotate.dmakesgenerate_xmrig_configabort after the long compile — exactly the kind of unfriendly failure this issue is about. A one-line guard fixes it; I reverted it from test: add sourceable test suite + Ubuntu E2E (closes #5) #26 to keep that PR scoped, so it's a good candidate to pick up here.The new test suite also gives this issue a place to assert friendlier failures once the ERR trap / build-output handling lands.
ci: add tag-driven release pipeline; complete the changelog (closes #36…