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.
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
[AOT] Added publishAOT test app to ensure OpenTelemetry SDK is AOT safe. #4392
[AOT] Added publishAOT test app to ensure OpenTelemetry SDK is AOT safe. #4392
Changes from all commits
ae1849f
324a7b2
46ddb20
4e04bc1
3c6ee77
60ef365
e9842d6
cd6e26e
ff307ab
58b7bd1
460205a
ce51034
e510df3
8f3e6be
e08c04d
4be2de8
ed371fe
a37eaf6
09bcb4c
446943a
a7eb400
010eed1
18c7afa
6409cdb
ea81b23
61ce597
4be236e
1e9b10b
618b742
28b81fc
29ba642
794d92c
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Curious - would it make sense to have the AOT test build as a separate CI job instead of using unit test here? (easier to turn on/off, can run in parallel with existing unit test pipelines, etc.)
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 thinking while we are still developing, i.e. the warnings are > 0, we keep this as a unit test so that it's easier to capture the expected number of warnings and run the test locally.
Once we fixed/suppressed all the warnings, we can bring it to be a CI to get the above mentioning benefits.
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.
You should be able to run the CI check locally as well.
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.
Sounds good to me 👍
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.
these can be achieved in the CI tasks itself
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.
Thank you for the info, Cijo : )
Please check out this comment: #4392 (comment)
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.
You may want to consider a way to baseline the existing warnings to start, and ensure new warnings aren't introduced as new features are added. I'm not sure the best way to do this, but maybe @vitek-karas @agocke or @sbomer knows of a good way?
In dotnet/sdk, we use the following method to verify the warnings (see the callers above this method):
https://github.com/dotnet/sdk/blob/7d23e9d3e4aad58a5b497d8d91a50ffdf148b238/src/Tests/Microsoft.NET.Publish.Tests/GivenThatWeWantToRunILLink.cs#L803-L834
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.
Other than baselining the output of the build I can't think of another way for NativeAOT right now.
ILLink supports suppressing warnings via XML files, which would be the best solution here, unfortunately that functionality isn't implemented in NativeAOT (it's on the list, but I don't know when it's going to happen).
NativeAOT does support suppressing warnings in code via assembly-level attributes, but those would have to go onto the assembly which produces the warnings, which is not useful to this case.