fix(release): sync Cargo.lock in create-release so it stops drifting (MAPPS-371) #431

Merged

nrupard merged 1 commit from fix/MAPPS-371-create-release-lock-sync into main

2026-07-15 18:32:17 +02:00

nrupard commented

2026-07-15 18:28:01 +02:00

Owner

Fixes MAPPS-371.

The apps create-release recipe bumped Cargo.toml + package.json but never updated Cargo.lock, so the lock's own mokosh-apps version drifted from the manifest: main was at Cargo.toml 0.7.1 (after the 0.7.0 / 0.7.1 releases) while Cargo.lock still pinned 0.6.0.

Effects: every cargo build rewrote the lock to match (each just pre-commit left M Cargo.lock), a --locked build failed, and the dirty lock would abort the next just create-release (which exits on a dirty tree).

Fix

Port the PMS-642 fix from mokosh-server into the apps create-release recipe: after the version bump, run cargo update --workspace in the rust-builder-glibc dev image (the same docker run ... $img cargo ... invocation pre-commit uses; dev boxes have no host cargo) and stage Cargo.lock alongside Cargo.toml / package.json in the release commit. --workspace limits the change to workspace members' own versions, no transitive dependency churn.
One-time: sync the currently-drifted lock (mokosh-apps 0.6.0 -> 0.7.1) so main builds clean under --locked and the next release starts from a clean tree.

Verification

just --show create-release parses; the new cargo update --workspace step and git add ... Cargo.lock are present.
The one-time sync changed only the mokosh-apps version line in Cargo.lock (0.6.0 -> 0.7.1), no other entries.
just pre-commit passes (fmt + clippy + wasm check + tests) and, with the lock now matching Cargo.toml, leaves Cargo.lock unchanged - the tree is no longer re-dirtied on build.

Fixes MAPPS-371. The apps `create-release` recipe bumped `Cargo.toml` + `package.json` but never updated `Cargo.lock`, so the lock's own `mokosh-apps` version drifted from the manifest: `main` was at `Cargo.toml` 0.7.1 (after the 0.7.0 / 0.7.1 releases) while `Cargo.lock` still pinned 0.6.0. Effects: every cargo build rewrote the lock to match (each `just pre-commit` left `M Cargo.lock`), a `--locked` build failed, and the dirty lock would abort the next `just create-release` (which exits on a dirty tree). ## Fix - Port the PMS-642 fix from mokosh-server into the apps `create-release` recipe: after the version bump, run `cargo update --workspace` in the rust-builder-glibc dev image (the same `docker run ... $img cargo ...` invocation `pre-commit` uses; dev boxes have no host cargo) and stage `Cargo.lock` alongside `Cargo.toml` / `package.json` in the release commit. `--workspace` limits the change to workspace members' own versions, no transitive dependency churn. - One-time: sync the currently-drifted lock (`mokosh-apps 0.6.0 -> 0.7.1`) so `main` builds clean under `--locked` and the next release starts from a clean tree. ## Verification - `just --show create-release` parses; the new `cargo update --workspace` step and `git add ... Cargo.lock` are present. - The one-time sync changed only the `mokosh-apps` version line in `Cargo.lock` (0.6.0 -> 0.7.1), no other entries. - `just pre-commit` passes (fmt + clippy + wasm check + tests) and, with the lock now matching `Cargo.toml`, leaves `Cargo.lock` unchanged - the tree is no longer re-dirtied on build.

nrupard added 1 commit

2026-07-15 18:28:01 +02:00

fix(release): sync Cargo.lock in create-release so it stops drifting (MAPPS-371)

Check / fmt + clippy + tests (pull_request) Successful in 1m25s

Details

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

Details

14815b9f59

The apps `create-release` recipe bumped `Cargo.toml` + `package.json` but never updated `Cargo.lock`, so the lock's own `mokosh-apps` version drifted: `main` was at `Cargo.toml` 0.7.1 while `Cargo.lock` still pinned 0.6.0. Every cargo build rewrote the lock to match (dirtying the tree on each `just pre-commit`), a `--locked` build failed, and the dirty lock would abort the next `create-release` (which exits on a dirty tree).

Port the PMS-642 fix from mokosh-server: after the version bump, run `cargo update --workspace` in the rust-builder-glibc dev image (same invocation as `pre-commit`; dev boxes have no host cargo) and stage `Cargo.lock` in the release commit. `--workspace` limits the change to workspace members' own versions, no transitive churn.

Also sync the currently-drifted lock (`mokosh-apps 0.6.0 -> 0.7.1`) so `main` builds clean under `--locked` and the next release starts from a clean tree. Verified: `just pre-commit` passes and leaves `Cargo.lock` unchanged (no re-dirty).

#MAPPS-371

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>