You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Unlike its siblings materialize_base_python_requirements.py and materialize_base_javascript_packages.py, which take an explicit --base-sha "$PR_BASE_SHA" and read blob content at that revision via git show <sha>:<path>, materialize_base_rust_toolchain.py takes no
revision argument and reads Cargo.toml / Cargo.lock / rust-toolchain* directly off the filesystem
(COVERAGE_SOURCE_WORKDIR), which is a merge of the base checkout with
the PR head already applied.
This means a PR that modifies its own Cargo.toml / Cargo.lock can
influence what the coverage sandbox's "base" Rust toolchain image
materializes and prefetches — the base-revision pin the Python/JS
materializers already enforce doesn't hold for Rust.
Flagged by CodeRabbit on #1052
(.github/workflows/opencode-review-dispatch.yml:638, "Heavy lift").
This repository has no Cargo.toml, so the bug doesn't affect this
repo's own coverage evaluation — it only affects sibling Rust repos.
Fixing it properly means mirroring the sibling _git() / git show <base_sha>:<path> pattern throughout materialize_base_rust_toolchain.py (tracked-path listing, TOML
reads, workspace-member glob expansion, and the file-copy step all
currently assume filesystem access), plus a full rewrite of tests/test_materialize_base_rust_toolchain.py's fixtures from
plain temp directories to real git repos with commits. That's a
separate, focused change, not a quick-win fix to bundle into fix(opencode): split review surfaces, give NIM two hours, and remove GitHub Models #1052.
Suggested fix
Add a required --base-sha argument, validate it with the existing SHA_RE pattern used elsewhere in scripts/ci/, and read Cargo.toml / Cargo.lock / rust-toolchain.toml / rust-toolchain
/ workspace member manifests via git ls-tree + git show <base_sha>:<path> instead of Path.is_file() / Path.read_text(),
mirroring materialize_base_python_requirements.py's _git() helper.
Summary
Unlike its siblings
materialize_base_python_requirements.pyandmaterialize_base_javascript_packages.py, which take an explicit--base-sha "$PR_BASE_SHA"and read blob content at that revision viagit show <sha>:<path>,materialize_base_rust_toolchain.pytakes norevision argument and reads
Cargo.toml/Cargo.lock/rust-toolchain*directly off the filesystem(
COVERAGE_SOURCE_WORKDIR), which is a merge of the base checkout withthe PR head already applied.
This means a PR that modifies its own
Cargo.toml/Cargo.lockcaninfluence what the coverage sandbox's "base" Rust toolchain image
materializes and prefetches — the base-revision pin the Python/JS
materializers already enforce doesn't hold for Rust.
Flagged by CodeRabbit on #1052
(
.github/workflows/opencode-review-dispatch.yml:638, "Heavy lift").Why deferred out of #1052
Cargo.toml, so the bug doesn't affect thisrepo's own coverage evaluation — it only affects sibling Rust repos.
_git()/git show <base_sha>:<path>pattern throughoutmaterialize_base_rust_toolchain.py(tracked-path listing, TOMLreads, workspace-member glob expansion, and the file-copy step all
currently assume filesystem access), plus a full rewrite of
tests/test_materialize_base_rust_toolchain.py's fixtures fromplain temp directories to real git repos with commits. That's a
separate, focused change, not a quick-win fix to bundle into fix(opencode): split review surfaces, give NIM two hours, and remove GitHub Models #1052.
Suggested fix
Add a required
--base-shaargument, validate it with the existingSHA_REpattern used elsewhere inscripts/ci/, and readCargo.toml/Cargo.lock/rust-toolchain.toml/rust-toolchain/ workspace member manifests via
git ls-tree+git show <base_sha>:<path>instead ofPath.is_file()/Path.read_text(),mirroring
materialize_base_python_requirements.py's_git()helper.