Merge Otel feature branch#2077
Conversation
…trace-core-into-dd-sdk-trace RUM-3294 Bundle dd-trace-core code into the dd-sdk-android-trace module
…sed on the new APM rules
…provide-sampling-tags-for-otel-spans RUM-3516 Provide the correct sampling priority for our Span events based on APM new rules
…ore-tracer-unit-tests RUM-3294 Add the Core Tracer tests
…e-into-otel Merge develop branch
…re-tracer-logger-implementation RUM-3405 Provide core tracer logger implementation
…ndle-with-rum-capability RUM-3249 Provide the bundleWithRum capability for OtelTracer
…el-contextstorage-custom-implementation RUM-3836 Provide the DatadogContextStorage for Opentelemetry
…el-bundle-with-logs-feature RUM-3250 Provide Otel bundle with logs feature
…odule-into-vendor-lib-app RUM-4508 Add OpenTelemetry use case into the vendor-lib sample
Co-authored-by: Bryce Eadie <[email protected]>
Co-authored-by: Bryce Eadie <[email protected]>
…/android/okhttp/TraceContext.kt Co-authored-by: Nikita Ogorodnikov <[email protected]>
…rent-otel-span-in-interceptor RUM-3438 Add the OkHttp Otel extensions module
Merge develop branch
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #2077 +/- ##
============================================
- Coverage 83.19% 67.59% -15.60%
============================================
Files 495 735 +240
Lines 17773 27019 +9246
Branches 2685 4563 +1878
============================================
+ Hits 14785 18261 +3476
- Misses 2256 7540 +5284
- Partials 732 1218 +486
|
| See the dedicated [Datadog SDK Android for OpenTelemetry documentation][2] to learn how to add a parent span to network requests made by the `OkHttp` library. | ||
|
|
||
| [1]: https://docs.datadoghq.com/real_user_monitoring/android/advanced_configuration/#automatically-track-network-requests | ||
| [2]: https://docs.datadoghq.com/tracing/trace_collection/custom_instrumentation/android?tab=kotlin |
There was a problem hiding this comment.
Is the second link expected to work yet? It doesn't currently but I couldn't find an alternative, guessing these docs just aren't published yet.
There was a problem hiding this comment.
yes the idea is to have this merge and release in the next version and then merge the documentation PR which is already opened.
| # We need separated steps for tracing module tests as these cannot be run with the CI visibility agent enabled. Also they need to be executed with | ||
| # the daemon capability as the worker threads are running as a daemon. | ||
|
|
||
| test:trace-debug: |
There was a problem hiding this comment.
do we still need dedicated job stages after all the changes done?
There was a problem hiding this comment.
not sure but I will check after I merge this and add a PR to clean the gitlab-ci if it turns out that it can be done without.
| buildFeatures { | ||
| buildConfig = true | ||
| } |
| com.squareup.okhttp3:okhttp:4.11.0 : 768 Kb | ||
| com.squareup.okio:okio-jvm:3.2.0 : 337 Kb |
There was a problem hiding this comment.
where it comes from? trace library shouldn't have its own transport, I was thinking we shouldn't have it after Moshi removal?
There was a problem hiding this comment.
I am pretty sure it is coming from something that is being used and not able to remove it but will double check it.
| @@ -413,85 +424,501 @@ public final class com/datadog/exec/DaemonThreadFactory : java/util/concurrent/T | |||
| public fun newThread (Ljava/lang/Runnable;)Ljava/lang/Thread; | |||
| } | |||
|
|
|||
| public class com/datadog/opentracing/DDSpan : com/datadog/trace/api/interceptor/MutableSpan, io/opentracing/Span { | |||
There was a problem hiding this comment.
are we going to verify binary compatibility of Java classes exposed through our Kotlin API? Do we break anything?
There was a problem hiding this comment.
these classes are exposed only for internal usage, we do not have a Java sample app for now but I did some try - outs. In any case these classes should not be used by our customers directly. It is the same case for the old Java code.
There was a problem hiding this comment.
Well, they were still publicly available (since Java doesn't have internal visibility modifier) and customer could downcast Span to DDSpan to do something, we didn't make any statement in the Javadoc saying they shouldn't be considered as a part of the public API. But I guess at the current point there is nothing we can do.
5 participants
What does this PR do?
A brief description of the change being made with this pull request.
Motivation
What inspired you to submit this pull request?
Additional Notes
Anything else we should know when reviewing?
Review checklist (to be filled by reviewers)