fix(release): sync Cargo.lock on release and correct main's drift (PMS-642) #435

Merged

nrupard merged 3 commits from fix/PMS-642-release-syncs-cargo-lock into main 2026-07-09 17:20:29 +02:00

Conversation 0 Commits 3 Files changed 2 +10 -3

nrupard commented 2026-07-09 16:55:03 +02:00

Owner

Copy link

Background

The create-release <major|minor|hotfix> recipe (justfile) bumps the [package] version line in Cargo.toml and commits it, but never runs cargo update. So Cargo.lock's mokosh-server entry keeps the OLD version. After the v0.6.0 release merged, main's Cargo.lock still says:

[[package]]
name = "mokosh-server"
version = "0.5.0"

while Cargo.toml says 0.6.0.

Consequences: every cargo invocation re-dirties Cargo.lock (auto-correcting the version line), a --locked build fails on the mismatch, and every branch cut from main inherits the drift (observed on the PMS-640 branch, where a container cargo check silently rewrote the lock).

bunyip's release recipe runs cargo update --workspace to keep its lock in sync (bunyip CLAUDE.md); mokosh's create-release does not.

Goal

A release leaves Cargo.lock in sync with the bumped Cargo.toml, and main's current drift is corrected.

Proposed approach

• Correct main now: sync the lock's mokosh-server entry to 0.6.0 and commit Cargo.lock.
• Fix the recipe: after the Cargo.toml version bump and before the release commit, run cargo update --workspace (workspace-members-only, so transitive dependencies are not churned) to sync the lock, then git add Cargo.toml Cargo.lock. Dev boxes are toolchain-less, so run this one cargo step inside the dev server container (docker compose ... run --rm --no-deps server cargo update --workspace), mirroring the existing create-release-container split pattern in bunyip. Keep the host git/fj steps on the host.

Alternatives considered

• Run cargo update on the host in the recipe: rejected. Dev boxes have no host Rust toolchain (that is why the pre-commit and check recipes run cargo in a container).
• Leave it and document: rejected. The drift is a real --locked-build hazard and re-dirties the lock on every build, which masks genuine lock changes in diffs.
• cargo generate-lockfile / full cargo update: rejected. Both can churn transitive dependencies; --workspace restricts the change to the workspace members' own versions.

Acceptance criteria

• main's Cargo.lock mokosh-server entry matches Cargo.toml (0.6.0).
• create-release runs cargo update --workspace after the version bump and stages Cargo.lock, so a fresh release leaves the lock in sync.
• Only workspace-member versions change in the lock (no transitive dependency churn).
• The recipe comment documents the lock-sync step.

## Background The `create-release <major|minor|hotfix>` recipe (`justfile`) bumps the `[package] version` line in `Cargo.toml` and commits it, but never runs `cargo update`. So `Cargo.lock`'s `mokosh-server` entry keeps the OLD version. After the v0.6.0 release merged, `main`'s `Cargo.lock` still says: ``` [[package]] name = "mokosh-server" version = "0.5.0" ``` while `Cargo.toml` says `0.6.0`. Consequences: every `cargo` invocation re-dirties `Cargo.lock` (auto-correcting the version line), a `--locked` build fails on the mismatch, and every branch cut from `main` inherits the drift (observed on the PMS-640 branch, where a container `cargo check` silently rewrote the lock). bunyip's release recipe runs `cargo update --workspace` to keep its lock in sync (bunyip `CLAUDE.md`); mokosh's `create-release` does not. ## Goal A release leaves `Cargo.lock` in sync with the bumped `Cargo.toml`, and `main`'s current drift is corrected. ## Proposed approach - Correct `main` now: sync the lock's `mokosh-server` entry to `0.6.0` and commit `Cargo.lock`. - Fix the recipe: after the `Cargo.toml` version bump and before the release commit, run `cargo update --workspace` (workspace-members-only, so transitive dependencies are not churned) to sync the lock, then `git add Cargo.toml Cargo.lock`. Dev boxes are toolchain-less, so run this one cargo step inside the dev `server` container (`docker compose ... run --rm --no-deps server cargo update --workspace`), mirroring the existing `create-release-container` split pattern in bunyip. Keep the host git/fj steps on the host. ## Alternatives considered - Run `cargo update` on the host in the recipe: rejected. Dev boxes have no host Rust toolchain (that is why the pre-commit and check recipes run cargo in a container). - Leave it and document: rejected. The drift is a real `--locked`-build hazard and re-dirties the lock on every build, which masks genuine lock changes in diffs. - `cargo generate-lockfile` / full `cargo update`: rejected. Both can churn transitive dependencies; `--workspace` restricts the change to the workspace members' own versions. ## Acceptance criteria - [ ] `main`'s `Cargo.lock` `mokosh-server` entry matches `Cargo.toml` (`0.6.0`). - [ ] `create-release` runs `cargo update --workspace` after the version bump and stages `Cargo.lock`, so a fresh release leaves the lock in sync. - [ ] Only workspace-member versions change in the lock (no transitive dependency churn). - [ ] The recipe comment documents the lock-sync step.

nrupard added 1 commit 2026-07-09 16:55:03 +02:00

fix(release): sync Cargo.lock on release and correct main's drift ... e09f70db8b

The create-release recipe bumped Cargo.toml's version but never ran cargo update, so Cargo.lock's mokosh-server entry kept the old version. After v0.6.0 merged, main's lock said 0.5.0 while Cargo.toml said 0.6.0: every build re-dirtied the lock and a --locked build would fail.

Two changes: correct main now (cargo update --workspace set the lock's mokosh-server entry to 0.6.0, a one-line change with no transitive churn), and add that step to create-release so a release keeps the lock in sync. The bump step now runs `cargo update --workspace` in the dev server container (dev boxes have no host cargo) and stages Cargo.lock alongside Cargo.toml before the release commit; ensure-env is added as a dep so the container has its .env.

#PMS-642

nrupard added 1 commit 2026-07-09 17:02:43 +02:00

chore(release): drop no-op SQLX_OFFLINE from the cargo update step ... afec11e6b0

Review nit (PMS-642): cargo update only resolves the lockfile, it does not compile sqlx query macros, so SQLX_OFFLINE had no effect on that step. Remove it.

#PMS-642

nrupard scheduled this pull request to auto merge when all checks succeed 2026-07-09 17:15:47 +02:00

nrupard added 1 commit 2026-07-09 17:15:57 +02:00

Merge branch 'main' into fix/PMS-642-release-syncs-cargo-lock 7663cb3622

nrupard scheduled this pull request to auto merge when all checks succeed 2026-07-09 17:16:06 +02:00

nrupard merged commit a89cf26a3b into main 2026-07-09 17:20:29 +02:00

nrupard deleted branch fix/PMS-642-release-syncs-cargo-lock 2026-07-09 17:20:29 +02:00

nrupard referenced this pull request from a commit 2026-07-09 17:20:31 +02:00

Merge pull request 'fix(release): sync Cargo.lock on release and correct main's drift (PMS-642)' (#435) from fix/PMS-642-release-syncs-cargo-lock into main

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

psa-systems/mokosh-server!435

No description provided.