Closed mikelle-rogers closed 9 months ago
Tagging subscribers to this area: @dotnet/area-infrastructure-libraries See info in area-owners.md if you want to be subscribed.
Author: | mikelle-rogers |
---|---|
Assignees: | - |
Labels: | `area-Infrastructure-libraries`, `blocking-clean-ci`, `Known Build Error` |
Milestone: | - |
Tagging subscribers to this area: @dotnet/area-extensions-logging See info in area-owners.md if you want to be subscribed.
Author: | mikelle-rogers |
---|---|
Assignees: | - |
Labels: | `blocking-clean-ci`, `untriaged`, `area-Extensions-Logging`, `Known Build Error` |
Milestone: | - |
@elinor-fung based on this issue, looks like the added NoWarn from https://github.com/dotnet/runtime/pull/88827#issuecomment-1635044668 doesn't work anymore. Please take a look.
@dsplaisted Any ideas why NoWarn
occasionally doesn't disable the warning? Am I not understanding how this should work?
https://github.com/dotnet/runtime/blob/b0d4502a1b89071c27e1026ee836c2883d2670e9/src/libraries/Microsoft.Extensions.Logging.Abstractions/tests/Microsoft.Extensions.Logging.Generators.Tests/Microsoft.Extensions.Logging.Generators.targets#L11
It must be disabling it most of the time, otherwise we'd have a lot more than those 6 hits - every build would be hitting this.
No, I don't know why that would be happening.
@rainersigwald @dotnet/msbuild Any idea why a NoWarn
for a NETSDK warning code would seem to not always apply? (WarnAsError is enabled here).
It is interesting that this looks like it is happening on osx
only. does this ring a bill to anyone? I want to point out that the number of hits is climbing too.
It also looks like it only started happening after switching the runtime repo to build with .NET 8 Preview 7 instead of .NET 8 Preview 6 (the warning was added in Preview 6): https://github.com/dotnet/runtime/pull/90014
I don't think MSBuild's warning handling is any different between operating systems. My first thought was that MSBuild ignores NoWarn (for its own warnings, anyway) if MSBuildWarningsAsMessages already has a value or if you don't import Microsoft.Common.CurrentVersion.targets for whatever reason. It's possible MSBuild would mishandle it if you specify both WarnAsError and NoWarn for the same warning code...but I'm not 100% sure on that one.
Do you have any OS-specific logic that could lead to not importing Microsoft.Common.targets?
what is the next step here?
This looks strikingly similar to https://github.com/dotnet/msbuild/issues/8814 (fixed by https://github.com/dotnet/msbuild/pull/8954) - basically there was a concurrency issue that could in some cases cause some postprocessing of warnings to be skipped.
Can this be transfered to dotnet/msbuild? Or if you need this issue for other tracking as well - please create a new issue in dotnet/msbuild.
Please also attach or link binlog of the failed run that ignored the NoWarn
Tagging subscribers to this area: @dotnet/area-meta See info in area-owners.md if you want to be subscribed.
Author: | mikelle-rogers |
---|---|
Assignees: | - |
Labels: | `area-Meta`, `blocking-clean-ci`, `Known Build Error` |
Milestone: | 9.0.0 |
@JanKrivanek I have created the issue https://github.com/dotnet/msbuild/issues/9133 and attached the binlog there. We need to keep this runtime issue open for a while as CI test building will continue to fail till, we get the new SDK having the fixed msbuild.
This is not specific to MacOS as we have started to see the failures on Linux_musl arm64. We are seeing the failures with arm64
builds only though.
Thank you @tarekgh We'll take it through triage The arch might actually be just a timing factor in a concurency issue
fix is in installer release 8.0.100-rc.2.23425.1
We can't upgrade to an RC1 SDK yet as our .NET SDK upgrade policy requires signed builds. We made a few exceptions in the past but I don't think this case justifies that. cc @mmitche
FYI I am seeing this also happening in x64 and in release/8.0:
https://github.com/dotnet/runtime/pull/91918/checks?check_run_id=16837643737
Queue: Build Libraries Build osx x64 Debug
Failure message:
.dotnet/sdk/8.0.100-preview.7.23376.3/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(267,5): error NETSDK1206: (NETCORE_ENGINEERING_TELEMETRY=Build)
Found version-specific or distribution-specific runtime identifier(s): alpine-x64. Affected libraries: SQLitePCLRaw.lib.e_sqlite3. In .NET 8.0 and higher,
assets for version-specific and distribution-specific runtime identifiers will not be found by default. See https://aka.ms/dotnet/rid-usage for details.
do we know if sdk/8.0.100-preview.7.23376.3
has the msbuild fix?
do we know if
sdk/8.0.100-preview.7.23376.3
has the msbuild fix?
It doesn't have it. Fix was merged and inserted on Aug/24, v8.0.100-pre was created on Aug/8
removing blocking-clean-ci as it has not failed in 30 days
24-Hour Hit Count | 7-Day Hit Count | 1-Month Count |
---|---|---|
0 | 0 | 0 |
Closing, since both release/8.0[-staging] and main are using SDKs that have the fix now: https://github.com/dotnet/runtime/blob/91b2946fbcfcd7f6cd6c3ce65a6146efb7081173/global.json#L2-L3 https://github.com/dotnet/runtime/blob/50c01531acc9a95202b7ec457ff8de592c2555b7/global.json#L2-L3
Build Information
Build: https://dev.azure.com/dnceng-public/public/_build/results?buildId=371425 Build error leg or test failing: Build / Libraries Build osx arm64 Debug / Restore and Build Product Pull request: https://github.com/dotnet/runtime/pull/90049
Error Message
Fill the error message using step by step known issues guidance.
Known issue validation
Build: :mag_right: https://dev.azure.com/dnceng-public/public/_build/results?buildId=371425 Error message validated:
error NETSDK1206: Found version-specific or distribution-specific runtime identifier(s): alpine-x64. Affected libraries: SQLitePCLRaw.lib.e_sqlite3
Result validation: :white_check_mark: Known issue matched with the provided build. Validation performed at: 8/11/2023 10:14:34 PM UTCReport
Summary