Remove persistent build cache for self-hosted test runners

[sbryngelson]

Summary

• Removes the setup-build-cache.sh symlink mechanism from Phoenix and Frontier test jobs
• Replaces with rm -rf build to ensure a clean build on every CI run
• Benchmark jobs on both clusters are unaffected

Changes

• .github/workflows/phoenix/test.sh: remove cache setup, add rm -rf build
• .github/workflows/frontier/build.sh: remove cache setup, add rm -rf build (non-bench only)

[github-actions]

Claude Code Review

Head SHA: 48dc49e

Files changed: 2

• .github/workflows/frontier/build.sh
• .github/workflows/phoenix/test.sh

---

Summary

• Removes the setup-build-cache.sh-based persistent build cache from test CI jobs on Phoenix and Frontier
• Replaces with rm -rf build to guarantee a clean build directory on each run
• Benchmark jobs remain unaffected (the if [ "$run_bench" != "bench" ] guard is preserved on Frontier)
• Net change: -4 lines / +2 lines across 2 files

---

Findings

No correctness, security, or convention issues found.

Observations:

1. Intent is clear and well-scoped. The cache-busting logic is removed only for test jobs; the bench guard in frontier/build.sh is correctly preserved so benchmarks still benefit from incremental builds if desired.

2. rm -rf build is safe here. The build/ directory is a CMake output directory created by ./mfc.sh build. Removing it before rebuilding is the canonical way to force a clean build, equivalent to ./mfc.sh clean.

3. Comment removal is appropriate. The comment # Only set up build cache for test suite, not benchmarks and # Set up persistent build cache were explaining the old mechanism; their removal keeps the scripts clean.

4. No impact on benchmark jobs. The Frontier benchmark path skips the rm -rf build block (via the existing if [ "$run_bench" != "bench" ] guard), which matches the PR description.

---

Improvement Opportunities (optional)

• Consider adding a brief inline comment explaining why the clean build is forced (e.g., # Force clean build to avoid stale artifacts across runs), mirroring the intent described in the existing smoke-test comment just below in phoenix/test.sh.
• If setup-build-cache.sh is now unused, it may be worth removing or archiving the script to avoid confusion — though that is out of scope for this PR.

[github-actions]

Claude Code Review

Head SHA: 7df2de8eb55969a476d64333b3e0d1e10cafdaf6

Files changed: 3

• .github/workflows/frontier/build.sh
• .github/workflows/phoenix/bench.sh
• .github/workflows/phoenix/test.sh

---

Summary

• Removes the setup-build-cache.sh symlink-based cache mechanism from Phoenix and Frontier test jobs.
• Replaces it with unconditional rm -rf build to guarantee clean builds.
• Adds rm -rf build to Phoenix bench.sh (previously had no cache setup and no clean).
• Simple, focused change that reduces CI infrastructure complexity.

---

Findings

1. PR description says bench jobs are "unaffected", but their behavior does change

frontier/build.sh — the original code skipped cache setup entirely for bench jobs (no clean, no cache). After this PR, bench jobs on Frontier also get rm -rf build, meaning they now always do a clean build where before they could reuse whatever was in the build directory. Same applies to Phoenix bench (bench.sh now has rm -rf build added where it had nothing before).

This is likely intentional and arguably more correct (avoids stale build artifacts in benchmarks), but the PR description saying bench jobs are "unaffected" is inaccurate. Worth updating the description for clarity, especially since benchmark timing can be sensitive to cold-vs-warm build state.

2. Stale comment in phoenix/test.sh after cache removal

After removing the cache, the comment immediately following still reads:

# Build with retry; smoke-test cached binaries to catch architecture mismatches
# (SIGILL from binaries compiled on a different compute node).

"cached binaries" no longer applies — there is no cache. This comment should be updated (e.g., remove "cached" or rephrase to "freshly built binaries") to avoid confusing future readers.

---

Summary verdict

The core change is correct and sound — removing a symlink-based cache in favor of clean builds is simpler and eliminates a class of stale-artifact bugs. The two items above are minor: a misleading PR description and a one-word stale comment. No functional correctness issues.