mcpField
C
cargo-release

cargo-release

github.com/bobmatnyc开发78183 次安装15 周前更新
代码仓库

关于 cargo-release

cargo-release 是 trusty-tools monorepo 中 Rust crate 的发布操作流程，供需要升级版本并发布 crate 的维护者使用。它涵盖 SemVer 判定、依赖更新、质量门禁、打标签和发布，并规定相关 crate 的发布顺序。

主要功能

  1. 01依据提交类型判定 SemVer 版本
  2. 02更新工作区内的依赖版本
  3. 03发布前运行测试、Clippy 与格式检查
  4. 04按步骤提交、打标签并推送
  5. 05按依赖顺序发布 crate

适用场景

  1. 01发布 trusty-tools 中的单个 crate
  2. 02发布共享版本的 trusty-mpm-* crate
  3. 03发布共享库及其依赖 crate
  4. 04为二进制 crate 安装发布版本

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/bobmatnyc/claude-mpm-skills --skill cargo-release

安装后在 Claude Code 中输入/cargo-release确认已加载。

附带文件metadata.json

详细介绍

Cargo 发布流程

何时调用

当用户针对 trusty-tools 单体仓库中的任何 crate 说出“release”“publish”“bump version”“ship”“tag a release”或“cut a version”时，调用此流程。

Semver 版本升级规则

根据自上一个标签以来的提交历史确定版本增量：

提交类型升级幅度
BREAKING CHANGE 页脚或 ! 后缀（例如 feat!:）主版本（X.0.0）
feat: — 新功能，不含破坏性变更次版本（0.X.0）
fix:、chore:、refactor:、perf:、docs:、test:补丁版本（0.0.X）

对于 trusty-mpm-* 系列，所有 8 个 crate 共用一个工作区版本，无论改动涉及哪个 crate，都要一起升级。

Crate 名称与目录名称

Cargo 的 -p 标志使用 Cargo.toml 中的 name 字段，而不是目录名称：

目录Cargo 标志标签前缀
crates/trusty-git-analytics/-p tgatga-v
crates/open-mpm/-p open-mpmopen-mpm-v

其他所有 crate 的目录名称都与 crate 名称相同（例如，crates/trusty-search/ → -p trusty-search，标签为 trusty-search-v）。

10 步发布流程

按顺序执行各步骤。任何一步失败都应停止。

步骤 1 — 升级 crate 版本
# crates/<name>/Cargo.toml
[package]
version = "0.5.1"   # was 0.5.0

对于 trusty-mpm-*，版本在根目录 Cargo.toml 的 [workspace.package] 下设置。只需升级一次；所有 trusty-mpm-* crate 都会继承该版本。

步骤 2 — 更新工作区中的所有依赖 crate

如果其他 crate 固定了要升级的版本（例如，trusty-common = "0.4.20"），请将每处都更新为新版本。使用 grep 查找所有固定版本：

grep -r '"<old-version>"' crates/ --include="Cargo.toml"

完成步骤 2 前，绝不要提交步骤 1 的更改——不完整的更新会导致整个工作区的 cargo check 失败。

步骤 3 — 质量门禁：测试
cargo test -p <crate>

必须输出：test result: ok. N passed; 0 failed; ...

步骤 4 — 质量门禁：clippy
cargo clippy -p <crate> -- -D warnings

不得产生任何警告。open-mpm 的例外情况请参阅 rust-quality-gate。

步骤 5 — 质量门禁：格式检查
cargo fmt --check

不得产生任何输出（退出码为 0）。如有需要，使用 cargo fmt 修复。

步骤 6 — 提交版本升级
git add crates/<name>/Cargo.toml   # and any updated dependent Cargo.toml files
git commit -m "chore(<crate>): bump to v<version>"

示例：chore(trusty-memory): bump to v0.5.1

对于 trusty-mpm-* 系列：chore(trusty-mpm): bump to v0.7.0

步骤 7 — 创建 git 标签

标签格式：<crate-name>-v<version>

git tag trusty-memory-v0.5.1

示例：

  • trusty-search-v1.2.0
  • trusty-memory-v0.5.1
  • tga-v0.3.0
  • open-mpm-v0.2.1
  • trusty-mpm-cli-v0.7.0（每个 trusty-mpm-* crate 创建一个标签）
步骤 8 — 将标签推送到 GitHub
git push origin trusty-memory-v0.5.1

如果提交尚未推送到远程仓库，请先推送提交：

git push origin main   # or the current branch
git push origin trusty-memory-v0.5.1
步骤 9 — 发布到 crates.io
cargo publish -p trusty-memory

跨 crate 依赖的发布顺序：先发布依赖项，再发布使用方。如果同时发布 trusty-common 和 trusty-search，请先发布 trusty-common，等待索引传播（约 30 秒），再发布 trusty-search。

publish = false 的 crate — 跳过此步骤：有些 crate 不会发布到 crates.io。请检查 crate 的 Cargo.toml 中是否包含：

[package]
publish = false

已知不发布的 crate 包括仅供内部使用或与单体仓库紧密耦合的 crate。对此类 crate，请跳过步骤 9，直接执行步骤 10。

步骤 10 — 在本地安装二进制文件（仅限二进制 crate）

对于会生成二进制文件的 crate，发布后将其安装到 PATH：

cargo install --path crates/<dir> --locked

示例：

cargo install --path crates/trusty-search --locked
cargo install --path crates/trusty-mpm-cli --locked
cargo install --path crates/trusty-memory --locked

macOS 代码签名安全规则（关键）

切勿将发布二进制文件直接复制到 ~/.cargo/bin/：

# WRONG — causes EXC_CRASH / CODESIGNING on macOS
cp target/release/trusty-search ~/.cargo/bin/trusty-search

在 macOS 上，cargo build 会生成“临时链接器签名”的二进制文件。内核的代码签名缓存以 cdhash 为键。直接用 cp 覆盖 PATH 中已有的二进制文件，会导致内核保留过期的缓存身份。下次执行时，程序会在任何代码运行之前因 EXC_CRASH / CODESIGNING — Taskgated Invalid Signature 被终止，只输出 zsh: killed，没有任何输出——这与 OOM 终止无法区分，但两者毫无关联。

cargo install 会先写入临时路径，再以原子方式重命名，从而保持签名缓存一致。务必使用它。

如果不慎手动复制了文件，请按以下方法修复：

codesign --force --sign - ~/.cargo/bin/<binary>

trusty-mpm-* 系列发布

trusty-mpm-* 系列使用共享的工作区版本。请一同发布全部 8 个 crate：

  1. 在根目录 Cargo.toml 的 [workspace.package] 下更新 version。
  2. 对所有 trusty-mpm-* crate 运行质量检查：cargo test -p trusty-mpm-core、cargo test -p trusty-mpm-mcp 等。
  3. 提交：chore(trusty-mpm): bump to v<version>。
  4. 为每个 crate 单独打标签：trusty-mpm-core-v<version>、trusty-mpm-mcp-v<version>、trusty-mpm-daemon-v<version>、trusty-mpm-client-v<version>、trusty-mpm-cli-v<version>、trusty-mpm-tui-v<version>、trusty-mpm-telegram-v<version>、trusty-mpm-gui-v<version>。
  5. 按依赖顺序发布可发布的 crate（core → client → mcp/daemon/cli/tui/telegram/gui）。
  6. 安装二进制文件：cargo install --path crates/trusty-mpm-cli --locked。

跨 crate 库发布检查清单

发布共享库（trusty-common、trusty-mcp-core、trusty-embedder、trusty-symgraph）时：

  1. 更新库版本（步骤 1）。
  2. 更新所有依赖 crate 的 Cargo.toml 版本锁定（步骤 2）——使用 grep 查找每一处引用。
  3. 运行 cargo check（针对整个工作区），确认工作区在新版本下可以编译。
  4. 对每个依赖项运行 cargo test -p <lib> 和 cargo test -p <consumer>。
  5. 一并提交所有 Cargo.toml 更改——工作区构建是原子的。
  6. 首先发布库；等待约 30 秒，让索引完成同步。
  7. 按顺序发布依赖方。

所需证据

完成发布后，请报告：

Released: trusty-memory v0.5.1
Tag: trusty-memory-v0.5.1 (pushed to origin)
Published: https://crates.io/crates/trusty-memory/0.5.1
Installed: cargo install --path crates/trusty-memory --locked ✓
Test result: ok. 87 passed; 0 failed; 5 ignored
Clippy: clean
Fmt: clean

反面做法

  • 在 macOS 上用 cp 而非 cargo install 复制二进制文件——会导致 zsh: killed／代码签名崩溃。
  • 在新版本库依赖发布到 crates.io 之前发布依赖它的 crate。
  • 更新库版本后忘记更新依赖 crate 的版本锁定——会导致工作区编译失败。
  • 质量检查通过前就打标签——错误的标签需要后续补丁版本来修复。
  • 使用 cargo install 时不加 --locked——可能会解析出与测试时不同的依赖版本。
  • 跳过 trusty-mpm-* 的步骤 2——8 个 crate 必须保持共享工作区版本一致。

评论

支持 Markdown