examples/bazel: regenerate Cargo.lock against connectrpc 0.6.0 / buffa 0.6.0#124
Merged
Conversation
…a 0.6.0 The standalone bazel example's Cargo.lock had been pinned at connectrpc 0.3.1 / buffa 0.3.0 since the example landed. Cargo.toml was bumped to 0.6.0 in the 0.5.0 and 0.6.0 release PRs but the lock was never regenerated (it's a non-workspace manifest, so workspace-wide cargo update doesn't reach it). Regenerated with cargo update against the published 0.6.0 crates; transitive deps follow. The bazel example pulls crates from crates.io via crate_universe's crate.from_cargo, which reads this Cargo.lock directly. MODULE.bazel.lock is gitignored and regenerates on the next bazel build.
|
All contributors have signed the CLA ✍️ ✅ |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
The standalone bazel example's
Cargo.lockhad been pinned atconnectrpc 0.3.1/buffa 0.3.0since the example landed.Cargo.tomlwas bumped to 0.5.0 and then 0.6.0 in the release PRs, but the lock was never regenerated — it's a non-workspace manifest ([workspace]table is empty), so workspace-widecargo updatedoesn't reach it, and the example isn't built in CI.crates_universereads thisCargo.lockviacrate.from_cargo(cargo_lockfile = "//:Cargo.lock"), so a stale lock means abazel buildeither fails or quietly pulls 0.3.x.What
cargo updateagainst the now-publishedconnectrpc 0.6.0andbuffa 0.6.0crates. Transitive deps follow (tokio 1.50 → 1.52, etc.).MODULE.bazel.lockis gitignored and regenerates on the nextbazel build.Verified
cargo metadataresolves cleanly withconnectrpc 0.6.0/buffa 0.6.0. The bazel example is not in CI; fullbazel test //...requires a sibling~/src/buffacheckout forsetup.sh, which isn't part of the verification here.