-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Core] - Move core-tracing to @opentelemetry/api 0.20.0 #15672
Conversation
This pull request is protected by Check Enforcer. What is Check Enforcer?Check Enforcer helps ensure all pull requests are covered by at least one check-run (typically an Azure Pipeline). When all check-runs associated with this pull request pass then Check Enforcer itself will pass. Why am I getting this message?You are getting this message because Check Enforcer did not detect any check-runs being associated with this pull request within five minutes. This may indicate that your pull request is not covered by any pipelines and so Check Enforcer is correctly blocking the pull request being merged. What should I do now?If the check-enforcer check-run is not passing and all other check-runs associated with this PR are passing (excluding license-cla) then you could try telling Check Enforcer to evaluate your pull request again. You can do this by adding a comment to this pull request as follows: What if I am onboarding a new service?Often, new services do not have validation pipelines associated with them, in order to bootstrap pipelines for a new service, you can issue the following command as a pull request comment: |
/check-enforcer evaluate |
b730eb2
to
4724727
Compare
Looks good (and thankfully the source level changes are minimal, unlike last time). One other thing is to update for the core-tracing/cache.ts. You probably want to do this sooner, rather than later, so it'll be in place when you run some of the live test pipelines. CC: @xirzec |
@xirzec @richardpark-msft thanks Richard for the reminder! I made a few changes there to make it easier to catch early:
I'm hoping these changes are ok to make, but please let me know if that's not quite right or if you have suggestions |
ff81d06
to
c73087e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I reviewed the PR and it looks good to me, thanks for upgrading us!
I will defer to @richardpark-msft for approval.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm glad the actual changes are pretty minor!
This also reminded me to file #15732
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left a code change comment, but also just made an interesting discovery...
import * as fs from "fs"; | ||
import * as path from "path"; | ||
|
||
const validOpenTelemetryVersions = ["1.0.0-rc1", "0.20.0"]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just noticed that it looks like 1.0 has shipped: https://www.npmjs.com/package/@opentelemetry/api/v/1.0.0
Should we just update to that and GA this package instead? :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh wow! Oh wow! Oh wow!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But 1.0.0 has the next tag... and 0.20.0 has the latest tag
1bda8cd
to
27f588c
Compare
27f588c
to
7bdad9b
Compare
0389954
to
6a29b3a
Compare
@xirzec I addressed the feedback and implemented the changes we discussed offline (removal of the version collision runtime check and adding a sanity check in test to ensure future us remembers to think about compatibility) - any concerns with the latest changes? If not, should we merge this in? Especially wanted to call out the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bravo! 👏
} from "@azure/core-tracing"; | ||
import { tracingPolicy } from "../../src/policies/tracingPolicy"; | ||
|
||
class MockSpan extends NoOpSpan { | ||
class MockSpan implements Span { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
much simpler! Good discovery here
This reverts commit 153e4f7.
d032f34
to
885d670
Compare
What
Why
This is part of our effort to move everyone to OTel 0.20.0 - but we have to stage it due to a transitive dependency and a breaking change in OTel. This PR updates core-tracing to use the latest OTel, fixes any breaking changes, and moves packages that we can move to the latest version of core-tracing.
Once core-rest-pipeline 1.1.0 is GA'd we'll be able to move the rest of the packages over to the latest core-tracing as well.
Removing the version collision came out of an offline discussion after these changes were reviewed - since it's a common source of pain and hasn't added much benefit (tracer conflicts incompatibility was never a problem) we decided to remove that logic
and always grab a unique symbol per OT compatibility.
Callouts
The packages that are already on core-v2 will not be upgraded at this time - we'll coordinate that with the GA of core-rest-pipeline 1.1.0