test(build): #231 follow-up -- AVR Uno tar-extract e2e regression gate

[zackees]

Summary

Follow-up to #232. Adds an #[ignore]-gated integration test that drives a real AVR Uno build end-to-end through the tar-extract scenario described in #147 / #231:

1. Build the Uno blink project at proj_a/ via AvrOrchestrator.build() -- assert no fast-path hit (cold).
2. Sanity gate: same-project warm rebuild MUST hit the fast path -- isolates orchestrator/predicate regressions from tar-restore regressions.
3. Tar proj_a/ into memory, extract under a different parent directory (tmp_b/nested/run-b/deeper/), stomp mtimes to 2020-01-01.
4. Build at proj_b/. Assert: fast-path hit (reused cached artifacts in BuildResult::message), firmware.hex byte-identical to cold output, wall-clock faster than cold.

What this catches that #232's unit test cannot

• Orchestrator state persisted outside the watch set that gets invalidated by tar-extract.
• Fast-path predicate bugs that pass the per-layer unit tests but reject a legitimately-cached BuildResult.
• Absolute paths baked into build_fingerprint.json or compile DB that the predicate actually reads.

FBUILD_NO_ZCCACHE

The test sets FBUILD_NO_ZCCACHE=1 (via an RAII env-var guard). zccache has its own fingerprint-state machinery already covered by zccache_hit_across_workspace_rename.rs, and decoupling it here keeps this test focused on the fbuild-owned fast-path predicate that the #147 fix actually changed. If we ever observe zccache state failing to survive tar-restore in CI, that is a separate bug.

Test plan

• FBUILD_NO_ZCCACHE=1 uv run --script ci/test.py -p fbuild-build --test avr_build -- --ignored cache_survives_tar_extract_uno --nocapture -- passes locally (Windows): cold 1.50s, same-project warm 0.06s, post-tar-extract warm 0.06s
• uv run --script ci/test.py -p fbuild-build -- still green (new test correctly #[ignore]'d in default runs)
• uv run soldr cargo clippy --workspace --all-targets -- -D warnings -- clean

🤖 Generated with Claude Code

[coderabbitai]

Warning

Rate limit exceeded

@zackees has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 40 minutes and 13 seconds before requesting another review.

You’ve run out of usage credits. Purchase more in the billing tab.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 0ceb16f8-4a0e-4710-ad45-7f1a7842cae2

📥 Commits

Reviewing files that changed from the base of the PR and between 8b2c8f2 and 77e4640.

⛔ Files ignored due to path filters (1)

• Cargo.lock is excluded by !**/*.lock

📒 Files selected for processing (2)

• crates/fbuild-build/Cargo.toml
• crates/fbuild-build/tests/avr_build.rs

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch test/avr-uno-cache-survives-tar-extract

---

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.}