fix(release): correct lock-sync comments and gate stale lockfile #29

Merged

David merged 1 commit from fix/FJMCP-18-release-lock-comments into main

2026-06-23 02:19:03 +02:00

David commented

2026-06-23 02:14:38 +02:00

Owner

What

Corrects the create-release recipe comments imported by PR #28 (a sync from the multi-crate forgejo-cli) and adds a fail-fast lockfile gate.

Why

PR #28 copied forgejo-cli's recipe wording into forgejo-mcp. forgejo-mcp is a single crate, so the imported comments were false: there are no "three workspace members moving in lockstep", the version lives in the root Cargo.toml [package] table, and the recipe uses cargo update --offline --package forgejo-mcp --precise, not cargo update --workspace. The comments now match the code and reference FJMCP-18.

Functional state (confirmation)

The lock sync itself already worked. Release commit 0c58328 (v0.2.2), cut after the lock-sync fix landed in 1962ad4, includes Cargo.lock alongside Cargo.toml. The release that omitted the lock was v0.2.1 (752ccfe), cut before the fix. FJMCP-18 itself was the v0.2.0 tag-build failure (cargo build --release --locked rejecting an out-of-sync lock).

New gate

After the version bump, cargo metadata --offline --locked runs and aborts the release if Cargo.lock is still out of sync with the bumped manifest. This mirrors CI's cargo build --release --locked so the FJMCP-18 failure surfaces at release-creation time (loud, local) instead of at tag-build time (silent until CI). Verified both directions: passes on a synced lock, blocks on a deliberately desynced one.

just pre-commit passes (fmt, clippy, build, test).

## What Corrects the `create-release` recipe comments imported by PR #28 (a sync from the multi-crate `forgejo-cli`) and adds a fail-fast lockfile gate. ## Why PR #28 copied `forgejo-cli`'s recipe wording into forgejo-mcp. forgejo-mcp is a **single crate**, so the imported comments were false: there are no "three workspace members moving in lockstep", the version lives in the root `Cargo.toml` `[package]` table, and the recipe uses `cargo update --offline --package forgejo-mcp --precise`, not `cargo update --workspace`. The comments now match the code and reference FJMCP-18. ## Functional state (confirmation) The lock sync itself already worked. Release commit `0c58328` (v0.2.2), cut after the lock-sync fix landed in `1962ad4`, includes `Cargo.lock` alongside `Cargo.toml`. The release that omitted the lock was v0.2.1 (`752ccfe`), cut **before** the fix. FJMCP-18 itself was the v0.2.0 tag-build failure (`cargo build --release --locked` rejecting an out-of-sync lock). ## New gate After the version bump, `cargo metadata --offline --locked` runs and aborts the release if `Cargo.lock` is still out of sync with the bumped manifest. This mirrors CI's `cargo build --release --locked` so the FJMCP-18 failure surfaces at release-creation time (loud, local) instead of at tag-build time (silent until CI). Verified both directions: passes on a synced lock, blocks on a deliberately desynced one. `just pre-commit` passes (fmt, clippy, build, test).

David added 1 commit

2026-06-23 02:14:38 +02:00

fix(release): correct lock-sync comments and gate stale lockfile

Check / fmt + clippy + build + tests (pull_request) Successful in 41s

Details

Create release / Create release from merged PR (pull_request) Has been skipped

Details

7e45841908

PR #28 synced forgejo-mcp's create-release recipe from the multi-crate forgejo-cli and imported comments that are false for this repo: forgejo-mcp is a single crate, its version lives in the root Cargo.toml [package] table, and the recipe uses `cargo update --offline --package forgejo-mcp --precise` (not `cargo update --workspace` over "three workspace members"). The comments now describe the single-crate reality and reference FJMCP-18.

Add a fail-fast gate after the version bump: `cargo metadata --offline --locked` blocks the release if Cargo.lock is still out of sync with the bumped manifest, mirroring CI's `cargo build --release --locked` so the FJMCP-18 class of failure surfaces at release-creation time instead of at tag-build time in CI. The functional lock sync already worked (v0.2.2 included the lock; only v0.2.1, cut before the fix, omitted it); the gate prevents a future edit from silently regressing it.

Signed-off-by: David Randall <David@NiceGuyIT.biz>

#FJMCP-18