[PROF-11203] Bump minimum version of datadog-ruby_core_source to 3.4
#4323
Conversation
This file contains 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
**What does this PR do?** This PR bumps the minimum version of the `datadog-ruby_core_source` gem to 3.4.0. **Motivation:** This bump ensures that any customers upgrading dd-trace-rb also pick up the latest version of `datadog-ruby_core_source`. **Additional Notes:** N/A **How to test the change?** Green CI means all ok :)
Datadog ReportBranch report: ✅ 0 Failed, 22114 Passed, 1476 Skipped, 5m 25.23s Total Time |
|
Humm, interesting, a new profiler flaky spec. Investigating... |
BenchmarksBenchmark execution time: 2025-01-27 15:14:46 Comparing candidate commit 42edee9 in PR branch Found 0 performance improvements and 0 performance regressions! Performance is the same for 31 metrics, 2 unstable metrics. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #4323 +/- ##
=======================================
Coverage 97.73% 97.73%
=======================================
Files 1367 1367
Lines 82864 82864
Branches 4209 4209
=======================================
+ Hits 80985 80991 +6
+ Misses 1879 1873 -6 ☔ View full report in Codecov by Sentry. |
In CI we ran into a flaky failure from this spec: <https://app.circleci.com/pipelines/github/DataDog/dd-trace-rb/18799/workflows/001aa960-917a-4036-83e1-9965bdf5ff34/jobs/659509> ``` Failures: 1) Datadog::Profiling::Collectors::ThreadContext#sample timeline support when timeline is enabled when thread starts Waiting for GVL cpu-time behavior on Linux assigns all the cpu-time to the sample before Waiting for GVL started Failure/Error: expect(first_sample.values.fetch(:"cpu-time")).to be 12345 expected #<Integer:24691> => 12345 got #<Integer:44213> => 22106 Compared using equal?, which compares object identity, but expected and actual are not the same object. Use `expect(actual).to eq(expected)` if you don't care about object identity in this example. # ./spec/datadog/profiling/collectors/thread_context_spec.rb:1201:in `block (7 levels) in <top (required)>' # ./spec/spec_helper.rb:238:in `block (2 levels) in <top (required)>' # ./spec/spec_helper.rb:123:in `block (2 levels) in <top (required)>' # /usr/local/bundle/gems/webmock-3.23.0/lib/webmock/rspec.rb:39:in `block (2 levels) in <top (required)>' # /usr/local/bundle/gems/rspec-wait-0.0.9/lib/rspec/wait.rb:46:in `block (2 levels) in <top (required)>' Finished in 34.85 seconds (files took 1.67 seconds to load) 767 examples, 1 failure, 20 pending Failed examples: rspec ./spec/datadog/profiling/collectors/thread_context_spec.rb:1196 # Datadog::Profiling::Collectors::ThreadContext#sample timeline support when timeline is enabled when thread starts Waiting for GVL cpu-time behavior on Linux assigns all the cpu-time to the sample before Waiting for GVL started ``` This means that we observed more cpu-time than expected for the target thread. In theory, the thread should be completely stopped (since it's sleeping), so it should not have any cpu-time. In practice, I can imagine that it's not impossible to make the thread wake up spuriously -- to handle a signal, or it was woken up on some internal Ruby lock -- just for it to go back to sleep. The intention of this spec is to validate that all cpu-time is assigned to the first sample (before the waiting for GVL started), and none to the second, so I think we're OK with not coupling to an exact amount of cpu-time to expect.
p-datadog
approved these changes
Jan 27, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
What does this PR do?
This PR bumps the minimum version of the
datadog-ruby_core_sourcegem to 3.4Motivation:
This bump ensures that any customers upgrading dd-trace-rb also pick up the latest version of
datadog-ruby_core_source.Change log entry
Yes. Bump minimum version of
datadog-ruby_core_sourceto 3.4Additional Notes:
N/A
How to test the change?
Green CI means all ok :)