ci(build): extend debuginfo=0 + mold to linux-build (fix recurring rust-lld SIGBUS)

[AdaWorldAPI]

Summary

Pays down the recurring linux-build (stable) CI flake. That job was the only one still linking the full lance+datafusion test-binary set at workflow-level debuginfo=1 and without mold — it lacked the mitigation the test job (TD-CI-TEST-JOB-DEBUGINFO0) and test-with-coverage job (TD-CI-COVERAGE-MOLD-1) in rust-test.yml already carry and are green with.

It flaked twice (#525, #528) with the same hard linker crash:

rust-lld ... llvm::parallelFor(...)
collect2: fatal error: ld terminated with signal 7 [Bus error], core dumped
error: could not compile `lance-graph` (test "test_to_sql") ...

Signal 7 = object file truncated when the runner's link partition fills mid-link. The diffs that triggered it were doc/data-only, confirming it's a runner resource cliff, not a code regression.

Fix

Mirror the green sibling jobs exactly in build.yml's linux-build job (additive, 17 insertions, no deletions):

• job-level RUSTFLAGS: "-C debuginfo=0 -C target-cpu=x86-64-v3" — the load-bearing relief. Per the sibling jobs' measurements, dropping debuginfo cut per-binary link footprint ~73%, so the partition can't fill mid-link. CI never attaches a debugger, so debuginfo carries no value here.
• pinned rui314/setup-mold@9c9c13bf… step before the Swatinem cache — fast, low-memory linking, same as the test / test-with-coverage jobs.

No source or test change. YAML validated.

Note

A job-level RUSTFLAGS gives this job its own Swatinem cache key, so the first run after merge repopulates the linux-build cache (one slower run, then steady-state). Board: TD-CI-LINUX-BUILD-DEBUGINFO0 (Paid — confirm-on-green over the next few linux-build runs).

🤖 Generated with Claude Code

https://claude.ai/code/session_01CcpLeEC3XK8Eye53GKBVvi

---

Generated by Claude Code

[coderabbitai]

Warning

Review limit reached

@AdaWorldAPI, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 18 minutes and 12 seconds. Learn how PR review limits work.

Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file).

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits.

🚦 How do rate limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 929d2741-6b19-4db3-8254-4cef4df74465

📥 Commits

Reviewing files that changed from the base of the PR and between 77d8ca8 and 0230cf1.

📒 Files selected for processing (3)

• .claude/board/AGENT_LOG.md
• .claude/board/TECH_DEBT.md
• .github/workflows/build.yml

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}