tamada / oinkie / 34015538771
97%
main: 97%

LAST BUILD BRANCH: releases/v0.5.0
DEFAULT BRANCH: main
Ran
Jobs 1
Files 20
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 96.683%. Remained the same
34015538771

Pull #101

github

tamada 
fix: sync Cargo.lock when the version is bumped

`update_version.sh` rewrote the version in Cargo.toml, README.md and the
site's index, and left Cargo.lock alone. Cargo.lock names this package's
own version too, and the Containerfile builds with `cargo build
--locked`, which does not reconcile the two:

  error: cannot update the lock file because --locked was passed to
  prevent this

So the release flow broke the release it was preparing. `update version`
fires on a push to releases/vX.Y.Z, runs the script, and commits with
`git commit -a` -- Cargo.toml at the new version, Cargo.lock at the old
one, because nothing ran cargo in between. The next thing to happen is a
container build.

It had never bitten because v0.4.0's bump was done by hand (#74), and
whoever did it ran cargo at some point, so the lock came along. The
script path has never been exercised end to end against --locked.

It surfaces now rather than at release time because #96 put a container
build on every push. Without that it would have failed inside
publish.yaml, which tags before it builds -- leaving v0.5.0 tagged with
no image behind it.

`cargo update --workspace --offline` follows the rewrite. --workspace so
that only this package's own entry moves, --offline so that a release
runner resolves nothing from the network at that point. Between them the
change to the lock is a single line. `cargo generate-lockfile` would
also work and is the wrong tool: it rebuilds the lock whole, and
dependency resolutions can move with it. `cargo metadata` syncs it but
exits 101 doing so, which is not something to put in a script.

Verified from a clean tree at 0.4.0: the script takes it to 0.5.0,
`cargo build --locked` then passes where it exited 101 before, and the
light image builds and serves MCP -- which is the thing that was
actually broken. Still idempotent: a second run changes none of the four
files. The NII CRID that #76 exists to protect is untouched.

Closes #100

Co-Authored-By: Claude... (continued)
Pull Request #101: fix: sync Cargo.lock when the version is bumped

5305 of 5487 relevant lines covered (96.68%)

48.33 hits per line

Jobs
ID Job ID Ran Files Coverage
1 34015538771.1 20
96.68
 GitHub Action Run
Source Files on build 34015538771