Bump packaged libdatadog to 35.0.0#53
Merged
Merged
Conversation
Update LIB_VERSION to 35.0.0 (gem version 35.0.0.1.0) and refresh the per-artifact sha256 checksums in the Rakefile LIB_GITHUB_RELEASES table to match the v35.0.0 GitHub release assets, so the legacy download-based publish workflow keeps verifying downloads correctly.
This comment has been minimized.
This comment has been minimized.
Closed
libdatadog 35.0.0 raised its workspace MSRV to 1.87.0 (its rust-toolchain.toml pins channel 1.87.0), so installing the v35.0.0 `builder` crate fails under the previously pinned 1.85.1 with "requires rustc 1.87.0 or newer". Bump RUST_VERSION accordingly and update the per-target tarball checksums to match the 1.87.0 release.
The devshell pulled `rustc`/`cargo` straight from nixpkgs, so the Rust version floated with the channel (currently 1.91.1) and could diverge from the toolchain libdatadog is built with in CI. Add the `oxalica/rust-overlay` input and pin the toolchain to 1.87.0, matching the libdatadog 35.0.0 MSRV and the CI `RUST_VERSION`.
Introduce a `rust-toolchain.toml` so the pinned Rust version has a single source of truth, and have the Nix devshell read it via `fromRustupToolchainFile` instead of hard-coding the version. This mirrors libdatadog's own toolchain-file setup and means rustup users get the same toolchain as the devshell.
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 join this conversation on GitHub.
Already have an account?
Sign in to comment
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?
Package the libdatadog 35.0.0 release so consumers (notably dd-trace-rb) can
depend on the gem version
35.0.0.1.0, which carries the merged trace-exporterFFI work.
What does this PR do?
LIB_VERSIONto35.0.0inlib/libdatadog/version.rb(gem version35.0.0.1.0).sha256checksums in theLIB_GITHUB_RELEASEStable in
Rakefileto match the v35.0.0 GitHub release assets, so the legacydownload-based publish flow keeps verifying downloads correctly.
Both the legacy
publishworkflow (download + verify by hash) and the newerbuildworkflow key offLibdatadog::LIB_VERSION, so the version bump coversboth; only the legacy flow needed the checksum refresh.
How to test the change?
Confirm
vendor/libdatadog-35.0.0/<platform>/.../include/datadog/data-pipeline.hexists and that the gem resolves
Libdatadog::VERSION == "35.0.0.1.0".Additional Notes:
The new from-source
buildworkflow does not consume the libdatadog releasehashes (only the toolchain hashes, untouched here).
JIRA: