fix(release): sync Cargo.lock in create-release recipe #26

Merged

David merged 1 commit from fix/release-recipe-lock-sync into main

2026-06-22 20:48:27 +02:00

David commented

2026-06-22 20:47:09 +02:00

Owner

Problem (systemic)

Releases keep failing CI at the tag with cannot update the lock file Cargo.lock because --locked was passed. This is not a one-off bad lock: the create-release justfile recipe bumps the version in Cargo.toml, stages only Cargo.toml, and commits, so every release commit is born with Cargo.lock still pinning the previous version. CI's cargo build --release --locked then hard-fails. v0.2.0 (FJMCP-18) and v0.2.1 both failed this exact way.

Why Cargo.lock was never added

Governance's create-release.yml template only tags and publishes; it does no version bump. The bump lives in each project's per-repo justfile create-release recipe. The sibling Rust repos that already hit this sync the lock in the same commit:

claude-run: cargo update --package claude-run --precise $bare then git add Cargo.toml Cargo.lock
yotun: cargo update --offline --package yotun --precise $bare then git add Cargo.toml Cargo.lock
forgejo-cli (workspace): cargo update --workspace then git add Cargo.lock ...

forgejo-mcp's recipe was copied before that fix landed, so it omits the lock-sync step.

Fix

Recipe: add cargo update --offline --package forgejo-mcp --precise $bare after the Cargo.toml bump and stage Cargo.lock alongside Cargo.toml, matching the sibling pattern. Verified end-to-end: resetting the lock to the old version and running the command re-syncs it and cargo metadata --locked passes.
Also commit the already-bumped Cargo.lock (0.2.1) so current main is consistent with Cargo.toml and builds under --locked again.

just pre-commit is green (fmt, clippy, build, 41 tests).

Remaining (release re-trigger, maintainer call)

This makes main and all future releases buildable, but the existing v0.2.0 and v0.2.1 tags still point at commits with the stale lock, so those tagged release builds stay red until a tag is cut at a fixed commit. After this merges, cutting a fresh tag (e.g. re-point v0.2.1, or roll forward to v0.2.2) off the fixed main will produce a green release build. That tag/publish step is yours to take.

Fixes FJMCP-18.

## Problem (systemic) Releases keep failing CI at the tag with `cannot update the lock file Cargo.lock because --locked was passed`. This is not a one-off bad lock: the `create-release` justfile recipe bumps the version in `Cargo.toml`, stages only `Cargo.toml`, and commits, so every release commit is born with `Cargo.lock` still pinning the previous version. CI's `cargo build --release --locked` then hard-fails. v0.2.0 (FJMCP-18) and v0.2.1 both failed this exact way. ## Why Cargo.lock was never added Governance's `create-release.yml` template only tags and publishes; it does no version bump. The bump lives in each project's per-repo justfile `create-release` recipe. The sibling Rust repos that already hit this sync the lock in the same commit: - `claude-run`: `cargo update --package claude-run --precise $bare` then `git add Cargo.toml Cargo.lock` - `yotun`: `cargo update --offline --package yotun --precise $bare` then `git add Cargo.toml Cargo.lock` - `forgejo-cli` (workspace): `cargo update --workspace` then `git add Cargo.lock ...` forgejo-mcp's recipe was copied before that fix landed, so it omits the lock-sync step. ## Fix - Recipe: add `cargo update --offline --package forgejo-mcp --precise $bare` after the `Cargo.toml` bump and stage `Cargo.lock` alongside `Cargo.toml`, matching the sibling pattern. Verified end-to-end: resetting the lock to the old version and running the command re-syncs it and `cargo metadata --locked` passes. - Also commit the already-bumped `Cargo.lock` (0.2.1) so current `main` is consistent with `Cargo.toml` and builds under `--locked` again. `just pre-commit` is green (fmt, clippy, build, 41 tests). ## Remaining (release re-trigger, maintainer call) This makes `main` and all future releases buildable, but the existing `v0.2.0` and `v0.2.1` tags still point at commits with the stale lock, so those tagged release builds stay red until a tag is cut at a fixed commit. After this merges, cutting a fresh tag (e.g. re-point `v0.2.1`, or roll forward to `v0.2.2`) off the fixed `main` will produce a green release build. That tag/publish step is yours to take. Fixes FJMCP-18.

David added 1 commit

2026-06-22 20:47:09 +02:00

fix(release): sync Cargo.lock in create-release recipe

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

Details

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

Details

1962ad4884

The `create-release` justfile recipe bumped the version in Cargo.toml, staged only Cargo.toml, and committed. It never refreshed Cargo.lock, so every release commit was born with the lock pinning the previous version. CI's `cargo build --release --locked` then hard-failed at the tag with 'cannot update the lock file Cargo.lock because --locked was passed', which is exactly how the v0.2.0 and v0.2.1 release builds failed.

Governance's create-release.yml only tags and publishes; the version bump lives in each project's justfile recipe. The sibling Rust repos that already hit this (claude-run, yotun, forgejo-cli) sync the lock in the same commit. This recipe was copied before that fix landed. Add `cargo update --offline --package forgejo-mcp --precise $bare` and stage Cargo.lock alongside Cargo.toml so the release commit stays buildable under --locked.

Also commit the already-bumped Cargo.lock (0.2.1) so the current main is consistent with Cargo.toml and builds under --locked again.

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

#FJMCP-18