ci: every committed Cargo.lock is current #227

Merged

dcharlot merged 1 commit from ci/lockfiles-current into main 2026-10-13 00:55:37 -04:00

Conversation 0 Commits 1 Files changed 3 +199

dcharlot commented 2026-10-12 20:18:10 -04:00

Owner

Copy link

A new workflow, lockfiles, with one short job on the linux runner.

Why. The workspaces here depend on one another by path. A version bump in one leaves the lockfiles of its dependents behind, and nothing says so until a job that passes --locked fails on a change that never touched it. Stale locks have failed jobs this way repeatedly.

What it does. For each directory that holds a tracked Cargo.lock, scripts/check-lockfiles.sh runs cargo update --workspace --locked: cargo resolves the workspace against its lock and fails if the lock would change. No crate is downloaded and nothing is built; a cold run over the whole tree takes about half a minute. A stale lock is named together with the command that regenerates it. A lock that could not be checked (no network, a manifest that does not parse) fails the run under its own heading, so it is never read as current.

No paths: filter. A filter on this forge matches the files of the push, not of the pull request, so a later push that touches no manifest would leave the head without a run of this check. The job is short enough to run on every push.

One directory is skipped, with its reason in the script: the vendored crate under jouledesk-rs/vendor, which cargo resolves against its parent workspace's lock. A skip entry that no longer names a lockfile fails the run.

Evidence.

• scripts/check-lockfiles-selftest.sh (run by the job) builds a scratch workspace and shows the check passes a current lock and fails four broken ones: a bumped path dependency, an added dependency, a missing lock, and a manifest that does not parse.
• On this tree, bumping one workspace's version (sandbox-rs) made the check name eight stale workspaces, each a path dependent; restored, it passes.
• With the check made to always exit 0, the self-test fails four of its five cases.
• check-workflow-concurrency.sh passes with the new workflow.

🤖 Generated with Claude Code

A new workflow, `lockfiles`, with one short job on the `linux` runner. **Why.** The workspaces here depend on one another by path. A version bump in one leaves the lockfiles of its dependents behind, and nothing says so until a job that passes `--locked` fails on a change that never touched it. Stale locks have failed jobs this way repeatedly. **What it does.** For each directory that holds a tracked `Cargo.lock`, `scripts/check-lockfiles.sh` runs `cargo update --workspace --locked`: cargo resolves the workspace against its lock and fails if the lock would change. No crate is downloaded and nothing is built; a cold run over the whole tree takes about half a minute. A stale lock is named together with the command that regenerates it. A lock that could not be checked (no network, a manifest that does not parse) fails the run under its own heading, so it is never read as current. **No `paths:` filter.** A filter on this forge matches the files of the push, not of the pull request, so a later push that touches no manifest would leave the head without a run of this check. The job is short enough to run on every push. **One directory is skipped,** with its reason in the script: the vendored crate under `jouledesk-rs/vendor`, which cargo resolves against its parent workspace's lock. A skip entry that no longer names a lockfile fails the run. **Evidence.** - `scripts/check-lockfiles-selftest.sh` (run by the job) builds a scratch workspace and shows the check passes a current lock and fails four broken ones: a bumped path dependency, an added dependency, a missing lock, and a manifest that does not parse. - On this tree, bumping one workspace's version (sandbox-rs) made the check name eight stale workspaces, each a path dependent; restored, it passes. - With the check made to always exit 0, the self-test fails four of its five cases. - `check-workflow-concurrency.sh` passes with the new workflow. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

dcharlot added 1 commit 2026-10-12 20:18:11 -04:00

ci: every committed Cargo.lock is current ... e22955434f

The workspaces here depend on one another by path, so a version bump in one
leaves its dependents' lockfiles behind. Only jobs that pass --locked notice,
and they fail on changes that never touched them. This job resolves each
workspace against its lock on every push (cargo update --workspace --locked:
no crate is downloaded and nothing is built) and names the stale ones with the
command that fixes each. A self-test shows the check fails on a bumped path
dependency, an added dependency, a missing lock and an unparseable manifest.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

dcharlot merged commit f712c3f5c5 into main 2026-10-13 00:55:37 -04:00

dcharlot referenced this pull request from a commit 2026-10-13 00:55:38 -04:00

Merge pull request 'ci: every committed Cargo.lock is current' (#227) from ci/lockfiles-current into main

dcharlot referenced this pull request from a commit 2026-10-14 02:13:13 -04:00

Merge origin/main (at 1fa13396, with D2b #221, #227 and #228) into wai/d2c-decoders-on-ops

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

Transaction-Science/open-standards!227

No description provided.