chore(deps): adopt upstream soldr/zccache/setup-soldr updates#253
Conversation
- rust-toolchain.toml: add `profile = "minimal"` (matches soldr/zccache)
- Cargo.toml: bump zccache-artifact 1.4.0 -> 1.8 (API-compatible per semver)
- pyproject.toml: bump zccache>=1.2.13 -> >=1.8.2
- .github/workflows/*.yml (9 files): replace deprecated `target-cache: true`
with `target-cache-profile: thin-v1` (modern setup-soldr input)
- crates/fbuild-build/tests/flag_escaping_lint.rs: extend allowed_files to
cover the post-LOC-split submodule files (methods.rs, build.rs, mod.rs);
the recent board.rs / esp32 orchestrator.rs / stm32 orchestrator.rs
splits moved canonical define code into renamed files but the lint's
allowlist was never updated, breaking the test on main.
`running-process-core` is intentionally NOT bumped: published 3.4.x dropped
the `Containment` enum and `spawn_with_containment` method that fbuild's
git-pinned rev relies on; moving off the pin requires refactoring
fbuild-core::{subprocess,containment} onto `ContainedProcessGroup`. See
#32.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
Warning Rate limit exceeded
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 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 configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (10)
📝 WalkthroughWalkthroughThis PR updates GitHub Actions workflow soldr cache configuration from a boolean flag to a named profile (thin-v1) across nine CI workflows, bumps Rust and Python package versions for zccache and zccache-artifact, adds a minimal Rust toolchain profile, and expands test allowlist coverage for escaped-quote patterns in split canonical source files. ChangesSoldr Cache Profile, Dependency, and Configuration Updates
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~4 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/bench-205.yml (1)
38-43:⚠️ Potential issue | 🟠 MajorFix invalid setup-soldr inputs in .github/workflows/bench-205.yml (lines 38-43)
zackees/setup-soldr@v0docs don’t listtarget-cache-profile; they listtarget-cache-mode(values:hot,full,off). Replacetarget-cache-profile: thin-v1with the documented input (and value).🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/bench-205.yml around lines 38 - 43, Replace the invalid input key target-cache-profile used in the zackees/setup-soldr@v0 step with the documented input target-cache-mode and set it to a valid value (e.g., target-cache-mode: hot); update the block where setup-soldr is configured (the step named "Setup soldr") to use target-cache-mode: hot instead of target-cache-profile: thin-v1.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@Cargo.toml`:
- Line 68: The Cargo.toml currently references a non-existent crate version for
zccache-artifact ("1.8"); update the dependency declaration for zccache-artifact
to a published crates.io version (e.g., "1.3.9" or the exact version you want),
or if "1.8" is intentional, add/present the alternate registry or git/source
reference (and its exact URL/revision) so Cargo can resolve it; locate the
zccache-artifact entry in Cargo.toml and replace the version string or add a
registry/git specification accordingly.
---
Outside diff comments:
In @.github/workflows/bench-205.yml:
- Around line 38-43: Replace the invalid input key target-cache-profile used in
the zackees/setup-soldr@v0 step with the documented input target-cache-mode and
set it to a valid value (e.g., target-cache-mode: hot); update the block where
setup-soldr is configured (the step named "Setup soldr") to use
target-cache-mode: hot instead of target-cache-profile: thin-v1.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: d8b2481c-52f2-43f2-a729-9e36af8cdc51
⛔ Files ignored due to path filters (2)
Cargo.lockis excluded by!**/*.lockuv.lockis excluded by!**/*.lock
📒 Files selected for processing (13)
.github/workflows/acceptance-205.yml.github/workflows/bench-205.yml.github/workflows/check-macos.yml.github/workflows/check-ubuntu.yml.github/workflows/check-windows.yml.github/workflows/docs.yml.github/workflows/msrv.yml.github/workflows/template_build.yml.github/workflows/template_native_build.ymlCargo.tomlcrates/fbuild-build/tests/flag_escaping_lint.rspyproject.tomlrust-toolchain.toml
| shell-words = "1" | ||
| bincode = "1" | ||
| zccache-artifact = "1.4.0" | ||
| zccache-artifact = "1.8" |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
zccache-artifact 1.8 crates.io release notes
💡 Result:
I couldn’t find any crates.io “release notes” entry or changelog specifically for zccache-artifact v1.8 (e.g., “1.8.0” or “1.8.x”) in the sources I located. What I did find: - The crates.io page for the crate (overall listing) exists, but the version page details I found were for 1.3.8 and 1.3.9, not 1.8.x, and they don’t provide 1.8 release notes in the retrieved results. [1] - docs.rs for zccache_artifact describes the crate’s functionality (disk artifact cache, content-addressed storage, redb index), but it is API docs and not a versioned “1.8 release notes” changelog. [2] - GitHub compares I found are for tags like 1.3.8…1.3.9 and 1.4.7…1.4.8 (again not 1.8.x of zccache-artifact). [3][4] If you meant “zccache” (the overall project) v1.8.0 rather than the Rust crate “zccache-artifact” v1.8, the search results I saw were for PyPI zccache 1.8.0 (not crates.io release notes for zccache-artifact). [5] If you can share the exact version number you mean (e.g., zccache-artifact 1.8.0, 1.8.1, etc.) or a link to the crates.io version page, I can pull the release notes/changelog for that specific version.
Citations:
- 1: https://crates.io/crates/zccache-artifact
- 2: https://crates.io/crates/zccache-artifact/1.3.9
- 3: https://crates.io/crates/zccache-artifact/1.3.8/dependencies
- 4: https://pypi.org/project/zccache/1.8.0/
- 5: zackees/zccache@1.4.7...1.4.8
Fix dependency version: zccache-artifact = "1.8" appears not to exist on crates.io
- Looked up results did not show any
zccache-artifact1.8.xversion details/release notes; the available retrieved version pages were forzccache-artifact1.3.8/1.3.9. - Update
Cargo.toml(line 68) to the actually publishedzccache-artifactversion, or provide the exact crates.io version/link (or confirm an alternate registry/source) if1.8is intentional.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@Cargo.toml` at line 68, The Cargo.toml currently references a non-existent
crate version for zccache-artifact ("1.8"); update the dependency declaration
for zccache-artifact to a published crates.io version (e.g., "1.3.9" or the
exact version you want), or if "1.8" is intentional, add/present the alternate
registry or git/source reference (and its exact URL/revision) so Cargo can
resolve it; locate the zccache-artifact entry in Cargo.toml and replace the
version string or add a registry/git specification accordingly.
The modernized `target-cache-profile: thin-v1` input triggered
`build_cache_mode=once`, which pre-populates the target directory before
`soldr cargo build -p fbuild-cli -p fbuild-daemon` runs. setup-soldr
emits its own warning ("setup-soldr detected a pre-populated shared
target directory; a subsequent `soldr cargo build` using the same
--target-dir may fail with a missing .rmeta error") and the follow-up
build step then fails. ~40 board build jobs regressed on PR #253 because
of this.
The deprecated `target-cache: true` input still works in setup-soldr@v0
and matches the previously-passing main behavior. The deprecation is
just a label — setup-soldr hasn't removed it. Keep using it until we
investigate the correct combination of new inputs that doesn't trip the
shared-target-dir limitation, in a separate task.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
… regression) The latest setup-soldr (v0 -> 33e221e via PR #140) defaults `prebuild-deps: cargo-chef` ON. cargo-chef pre-warms `target/deps/` before the user's `cargo build`, but on fbuild's CI the prebuild leaves the shared target directory in a state that conflicts with the follow-up `soldr cargo build -p fbuild-cli -p fbuild-daemon` step (missing .rmeta errors). setup-soldr itself emits a warning about this exact failure mode and exposes `prebuild-deps: none` as the documented escape hatch. Apply `prebuild-deps: none` everywhere we invoke setup-soldr (10 workflow files, 11 invocations including bench-205's two blocks). This is a stop-gap. The proper fix is upstream: either prebuild-deps should not corrupt the target dir when subsequent `cargo build -p` calls follow, or fbuild should switch to a separate target-dir for the daemon/cli build. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
@coderabbitai resolving your two comments: 1. This is a false positive.
2. This comment is stale — it was filed against commit Both items addressed — proceeding to merge. |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: Length of output: 3 🏁 Script executed: Length of output: 27
🐇 ₍ᐢ..ᐢ₎ ♡ ✏️ Learnings added
|
1 participant
Summary
Brings fbuild in line with the latest releases of soldr, zccache, and setup-soldr (all published 2026-05-22).
profile = "minimal"to match soldr/zccachezccache-artifact1.4.0 → 1.8 (API-compatible per semver; verified bycargo check)zccache>=1.2.13→>=1.8.2target-cache: true→target-cache-profile: thin-v1(the modern setup-soldr input)flag_escaping_lint.rs— extendallowed_filesto cover the post-LOC-split submodules (methods.rs,build.rs,mod.rs); the lint was silently broken on main after the recentboard.rs/orchestrator.rssplitsDeferred
running-process-coreis not bumped. Published 3.4.x dropped theContainmentenum andspawn_with_containmentmethod that fbuild's git-pinned rev relies on; moving off the pin requires refactoringfbuild-core::{subprocess,containment}ontoContainedProcessGroup. Tracked separately.Test plan
uv run soldr cargo check --workspace --all-targets— cleanuv run soldr cargo clippy --workspace --all-targets -- -D warnings— cleanuv run soldr cargo test --workspace— 534 + supporting tests pass; the previously-brokenflag_escaping_lint::escaped_quote_usage_is_restrictednow passes too🤖 Generated with Claude Code
Summary by CodeRabbit
Chores
Tests