-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Add support for analyzers from ref-packs #18501
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
Conversation
I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label. |
Also add analyzers to conflict resolution.
61c03d2
to
70077b9
Compare
@dsplaisted @wli3 can one of you have a look at this and give some guidance around what might be missing? I did what I think might be the minimum to enable the scenario but I expect to need to do more :) |
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.
Looks good. Is there any way to have test coverage of analyzer conflict resolution?
src/Tasks/Microsoft.NET.Build.Tasks/ResolveTargetingPackAssets.cs
Outdated
Show resolved
Hide resolved
Did you have a suggestion for where to look for such tests, @dsplaisted? I saw tests of the conflict resolver itself, but nothing that tested the task level where this logic lives. I might be missing something though. |
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.
Looks good.
I added a test that forced inbox and OOB SDK analyzers to be used. I made it fail locally by disabling the conflict-resolution change in targets:
Then put my change back in place and it succeeds. I think this is ready to go. |
...sks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets
Show resolved
Hide resolved
Tested this with the work I have in PR in arcade/runtime and it's working as expected. Thanks folks! |
… log (#18501) Noticed in dotnet/installer#18409 that errors aren't propagated which resulted in builds not to fail. The fix here is to use `OnError` in the correct target (but only when using the minimal console log feature) and not set `IgnoreStandardErrorWarningFormat=true` on the Exec task that invokes the repo build script. I also cleaned targets up as those introduced unnecessary complexity and logged in cases when they shouldn't (i.e. in dotnet.proj or package-source-build.proj). This affected runtime which errors after 30s of building because of RuntimeOS and BaseOS being passed in in-correctly. Regressed with dotnet/installer@a265140#diff-86602308e6bb519266bc2f224ea65e39589d273804d40ad0f9c6e0eea2a263dc. Fixed that in runtime.proj. Kudos to Alexander who made the fix. I just copied it in form his CI PR.
… log (#18501) Noticed in dotnet/installer#18409 that errors aren't propagated which resulted in builds not to fail. The fix here is to use `OnError` in the correct target (but only when using the minimal console log feature) and not set `IgnoreStandardErrorWarningFormat=true` on the Exec task that invokes the repo build script. I also cleaned targets up as those introduced unnecessary complexity and logged in cases when they shouldn't (i.e. in dotnet.proj or package-source-build.proj). This affected runtime which errors after 30s of building because of RuntimeOS and BaseOS being passed in in-correctly. Regressed with dotnet/installer@37ddec7#diff-86602308e6bb519266bc2f224ea65e39589d273804d40ad0f9c6e0eea2a263dc. Fixed that in runtime.proj. Kudos to Alexander who made the fix. I just copied it in form his CI PR.
Also add analyzers to conflict resolution.
Implements https://github.com/dotnet/designs/blob/main/accepted/2021/InboxSourceGenerators.md