Skip to content

chore(toolchain): 给依赖版本建一份带绑定测试的单一真源 - #89

Merged
2233admin merged 1 commit into
mainfrom
chore/toolchain-version-manifest
Aug 1, 2026
Merged

chore(toolchain): 给依赖版本建一份带绑定测试的单一真源#89
2233admin merged 1 commit into
mainfrom
chore/toolchain-version-manifest

Conversation

@2233admin

Copy link
Copy Markdown
Owner

为什么

一致性自检——这台机器跑的是不是仓里声明的版本——现在得读五个文件、五种格式:

依赖 声明处 格式
Rust toolchain rust-toolchain.toml TOML 字段
PyYAML requirements-ci.txt pip + hash
ast-grep .github/workflows/ci.yml 硬编码在 shell 变量里
claude-code-merge-queue package.json JSON
repowise legacy/install-code-intel-pipeline.ps1 PowerShell 变量
code-intel crates/code-intel-cli/Cargo.toml TOML

让自检器去解析这五种,等于让它在别人改了 ci.yml 的引号写法时静默少检一项——正是这个仓反复出现的那个形状(doctor_provider_rows.rs:13-18"bootstrap reports ok while a present external provider is broken")。

改了什么

orchestration/toolchain-versions.v1.json 收敛成一种格式,附 code-intel-toolchain-versions.v1 schema(draft 2020-12,additionalProperties: false,与仓内其他 schema 同构)。

每条带 rationale一个没有记录理由的 pin 会腐烂成 cargo cult,而这里每个理由都是现成的:

  • rust-toolchain → 不 pin 会让发布产物不可复现
  • pyyaml → supply-chain-001 的 hash 锁定
  • repowise → supply-chain-003,不让 --upgrade 拉进未审核的版本
  • code-intel → 装机版落后会带来实测 39 倍的性能差(10.9s vs 0.28s)

绑定测试是这个 PR 的重点

第二真源如果会跟第一真源分叉,比没有第二真源更糟。 tests/toolchain_versions.rs 把清单逐条绑回真实声明处,5 个测试:

  1. 清单形状符合 schema
  2. 每条 version 等于真实声明处抓到的值
  3. 一个文件声明同一工具两次时不许自相矛盾
  4. 每个 probe 描述可执行
  5. 清单里的 code-intel 版本等于 CARGO_PKG_VERSION

绑定按「每一处匹配都必须一致」而不是「第一处匹配」。这不是理论问题:ci.ymlwindows-build-test-packagecross-platform-smoke 两个 job 里各装了一次 ast-grep,各有一份硬编码的 $version = '0.42.3'。改一处漏一处就是无声分叉,第 3 条测试专门盯它。

刻意排除的范围

「上游最新版本」不在这份清单里。 pin 是供应链控制和可复现性控制;把它跟「追最新」混在一起,等于把 pin 变成自动升级,supply-chain-001 的 hash 锁定和 rust-toolchain.toml 的可复现性都会失效。

上游新鲜度(声明是否落后于生态发布)是独立的一层,只报告不强制,另开。schema 的 description 里写明了这个边界。

本次只落声明侧

探测侧(真的去读机器版本并比对,接进 code-intel doctor)接着做,它会复用 #88 落地的 Get-ToolVersion / Test-ToolVersionProbeAllowed

清单在探测侧落地前是没有消费者的——但绑定测试本身已经有独立价值:它现在就在盯着 ci.yml 那两处 ast-grep 版本。

验证

  • cargo test -p code-intel --test toolchain_versions:5 passed
  • schema 校验:Test-Json -SchemaFile 通过(仓内既有做法)
  • cargo fmt -p code-intel -- --check:clean
  • 无新增依赖(mini-regex 手写,crate 目前只有 serde_json 一个依赖,不为六个 pattern 再加一个)

Refs #59

一致性自检(这台机器跑的是不是仓里声明的版本)现在得读五个文件、五种格式:
rust-toolchain.toml 的 TOML 字段、requirements-ci.txt 的 pip + hash、ci.yml 里
硬编码在 shell 变量中的 ast-grep 版本、package.json、以及安装器里的
$script:RepowisePinnedVersion。让自检器去解析这五种,等于让它在别人改了
ci.yml 的引号写法时静默少检一项——正是这个仓反复出现的那个形状。

orchestration/toolchain-versions.v1.json 收敛成一种格式,附
code-intel-toolchain-versions.v1 schema。每条带 rationale:一个没有记录理由的
pin 会腐烂成 cargo cult,而这里每个 pin 的理由都是现成的(可复现构建、
supply-chain-001 的 hash 锁定、supply-chain-003 的不拉未审核版本)。

第二真源如果会跟第一真源分叉,比没有第二真源更糟,所以
tests/toolchain_versions.rs 把清单逐条绑回真实声明处。绑定按「每一处匹配都必须
一致」而不是「第一处匹配」:ci.yml 在 windows job 和 cross-platform matrix 里各
装了一次 ast-grep,各有一份硬编码版本,改一处漏一处就是无声分叉。现在有一条
测试专门盯着这个重复。

范围上刻意排除了「上游最新版本」。pin 是供应链控制和可复现性控制,把它跟
「追最新」混在一起就等于把 pin 变成自动升级。上游新鲜度是独立的一层,只报告
不强制,另开。

本次只落声明侧。探测侧(真的去读机器版本并比对)接着做,它会复用 #88 落地的
Get-ToolVersion / Test-ToolVersionProbeAllowed。

Refs #59
@gemini-code-assist

Copy link
Copy Markdown

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.

@repowise-bot

repowise-bot Bot commented Aug 1, 2026

Copy link
Copy Markdown

🔒 Repowise is not analyzing this repository

The PR bot is free on public repositories. This one is private, which needs a Pro plan.

See plans · Manage this repository

@coderabbitai

coderabbitai Bot commented Aug 1, 2026

Copy link
Copy Markdown

Warning

Review limit reached

@2233admin, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 9 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

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

How do review limits work?

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

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, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 398cf4e5-79c3-48e1-bf35-1490d28f81fa

📥 Commits

Reviewing files that changed from the base of the PR and between df2ba17 and baa9be6.

📒 Files selected for processing (3)
  • crates/code-intel-cli/tests/toolchain_versions.rs
  • orchestration/schemas/code-intel-toolchain-versions.v1.schema.json
  • orchestration/toolchain-versions.v1.json

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

Comment @coderabbitai help to get the list of available commands.

@2233admin
2233admin merged commit a682be4 into main Aug 1, 2026
7 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant