Stop committing Cargo.lock - #8
Conversation
The workspace consumes the AdaWorldAPI/ndarray fork by git branch, and the committed lock pinned it to e55af0e3 (PR sonos#297) while the branch head was f43338fb (PR sonos#299), so every build silently used a two-merge-old dependency that predated the AVX-512 test-blind-spot fix. Removing the lock and ignoring it makes the branch pin mean what it says; verified by re-resolving, which now reports f43338fb. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QDLGAoWFEqDqUiHJGgNvuu
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_f422e943-8760-4a06-a46c-9955b91e8d8c) |
This reverts commit e4f12e2.
Cargo.lock pinned the ndarray fork at e55af0e3 while the branch it names had advanced to f43338fb, so every build silently used a two-merge-old dependency. A `branch = "..."` dependency is a moving target but the lock records one revision, and nothing compared the two. Updates the pin and adds a CI check that fails with the exact `cargo update` needed when a lock's git-branch revision falls behind its branch head. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QDLGAoWFEqDqUiHJGgNvuu
|
The job's third
No fix exists to port: making it green needs either a The rest of CI is green on this PR: 30+ checks passing including Generated by Claude Code |
Restores the lock removal. It was reverted on the strength of a non-answer to a question about how to handle the release workflow's --locked build; the instruction to remove the lock stood and should not have been reversed. Drops the lock-freshness CI check with it, since it has nothing to check without a lock. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QDLGAoWFEqDqUiHJGgNvuu
The flag requires a committed Cargo.lock, which this repo does not carry, so a tagged release would fail before building. cargo-auditable still embeds the resolved dependency graph, so the SBOM is unaffected. The --locked on the cargo-auditable install above is unrelated: it pins that tool's own lockfile from the registry. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QDLGAoWFEqDqUiHJGgNvuu
…hydration-fp4dyc # Conflicts: # Cargo.lock
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 13250194d2
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| # AdaWorldAPI/ndarray fork by git branch, and a committed lock pins a stale | ||
| # revision of it (measured: the lock held ndarray e55af0e3 while the branch | ||
| # was at f43338fb, so builds silently used a two-merge-old dependency). | ||
| Cargo.lock |
There was a problem hiding this comment.
On any persistent developer checkout, the first Cargo command recreates this ignored Cargo.lock, and subsequent builds continue honoring the git revision recorded there rather than refreshing the master branch. This therefore fixes the stale ndarray revision only once and then recreates the same stale-branch problem invisibly—git status will not expose it—so experiments intended to exercise later fork changes can silently run older code unless the developer explicitly deletes the lock or runs cargo update.
Useful? React with 👍 / 👎.
| # revision of it (measured: the lock held ndarray e55af0e3 while the branch | ||
| # was at f43338fb, so builds silently used a two-merge-old dependency). |
There was a problem hiding this comment.
The recorded commit IDs and “two-merge-old” measurement describe a one-time repository state rather than the current contract; as soon as the branch advances, this explanation becomes stale while remaining in the configuration. State the durable reason for the ignore rule without narrating the prior lock contents.
AGENTS.md reference: AGENTS.md:L272-L272
Useful? React with 👍 / 👎.
2 participants
Removes
Cargo.lockandtools/asset-mirror/Cargo.lockfrom the repo and ignores both, because the committed lock was pinning the ndarray fork to a stale revision and silently overriding the branch pin in[patch.crates-io].Measured: the lock held
ndarrayate55af0e3(PR sonos#297) whileorigin/masterwas atf43338fb(PR sonos#299), so every build resolved a dependency two merges behind the branch it claims to track — including builds intended to exercise the sonos#299 AVX-512 test-blind-spot fix. After removal,cargo metadataresolvesgit+https://github.com/AdaWorldAPI/ndarray?branch=master#f43338fb53bdbffec68c3a95adebdbbe7c9d4178.Verified
cargo metadatacompletes with no lock present in this workspace. One consequence worth naming: without a lock, a semver-compatible bump in a transitive dependency can change a build with no commit here — if bit-reproducible releases of thetractCLI matter later, the fix is--lockedin CI against a lock generated at build time, not re-committing one.🍍
🤖 Generated with Claude Code
https://claude.ai/code/session_01QDLGAoWFEqDqUiHJGgNvuu
Generated by Claude Code