-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Open
Labels
Area-WatchKnown Build ErroruntriagedRequest triage from a team memberRequest triage from a team member
Description
Build Information
Build: https://dev.azure.com/dnceng-public/public/_build/results?buildId=932408
Build error leg or test failing: dotnet-sdk-public-ci
Error Message
{
"ErrorMessage" : "because the file extension '.fsproj' is not associated with a language",
"BuildRetry" : false,
"ExcludeConsoleLog" : false
}
- PR: [ApiDiff] Update symbol filtering code to be able to load a list of strings or a list of files #46255
- Queue: FullFramework: windows (x64)
- Job result: https://dev.azure.com/dnceng-public/public/_build/results?buildId=932408&view=logs&j=2709a726-7db6-5829-ca7b-958b9d664f9e&t=9c6bf218-1bed-58a8-ccb2-7aefc7e3994e
- Log file: https://helixr1107v0xdeko0k025g8.blob.core.windows.net/dotnet-sdk-refs-pull-46255-merge-f03a79adaa674a1187/dotnet-watch.Tests.dll.1/1/console.1a860fa0.log?helixlogtype=result
- Output:
dotnet watch ⚠ msbuild: [Failure] Cannot open project
'C:\h\w\B34E099A\t\dotnetSdkTests\geksol2n.pb2\RenameSourceF---5F6BBE1E\FSharp\Lib.fsproj'
because the file extension '.fsproj' is not associated with a language.
Known issue validation
Build: 🔎 https://dev.azure.com/dnceng-public/public/_build/results?buildId=932408
Error message validated: [because the file extension '.fsproj' is not associated with a language
]
Result validation: ✅ Known issue matched with the provided build.
Validation performed at: 1/28/2025 10:53:09 PM UTC
Report
Build | Definition | Step Name | Console log | Pull Request |
---|---|---|---|---|
2771298 | dotnet-sdk | Run dotnet-format on dotnet/aspnetcore AspNetCore.sln | Log | #52300 |
Summary
24-Hour Hit Count | 7-Day Hit Count | 1-Month Count |
---|---|---|
5 | 15 | 73 |
Metadata
Metadata
Assignees
Labels
Area-WatchKnown Build ErroruntriagedRequest triage from a team memberRequest triage from a team member
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
baronfel commentedon Jan 28, 2025
I thought @tmat already fixed this with a servicing fix to the 9.0.1xx releases? It should be in 102 or 103?
tmat commentedon Jan 28, 2025
The warning is not the reason why the test failed.
tmat commentedon Jan 28, 2025
This commit hasn't been integrated to main yet: 3cd7c65
Forgind commentedon Feb 12, 2025
@tmat, just hit this issue in #45419, which is targeting release/9.0.3xx. I don't think this worked.
Forgind commentedon Feb 12, 2025
https://helixr1107v0xdeko0k025g8.blob.core.windows.net/dotnet-sdk-refs-pull-45419-merge-3ed9793f78ef4bc6b6/dotnet-watch.Tests.dll.1/1/console.dd2344c8.log?helixlogtype=result
tmat commentedon Feb 12, 2025
@Forgind You can ignore Mac ARM64 failures. The machines are slow and the tests time out.
Forgind commentedon Feb 13, 2025
Can you explain that a bit further? @marcpopMSFT told me that those machines should actually be faster than the x64 machines. That said, we've also had a lot of timeouts and are actively working on figuring out why (without success as of yet, hence the PR I linked). It may be that we've just misunderstood where the issue is on that leg, and we should just increase the timeout across the board.
tmat commentedon Feb 13, 2025
@Forgind Not sure what the status is right now, but the Mac ARM64 CI leg has been optional for a while.
Forgind commentedon Feb 13, 2025
It's optional right now because it's been timing out, but we've been trying to figure out why it keeps timing out so we can turn it back on. I don't know that it's just automatically slow.
tmat commentedon Feb 13, 2025
Oh, I see. So in this specific case the logs show that
dotnet build
is taking very long time. Not sure where it gets stuck:Seems like memory dumps were saved but I don't see them in the artifact list.
marcpopMSFT commentedon Feb 13, 2025
To clarify, forgind was trying to get context on your comment that the arm64 machines are slow. Ever since we added that leg, it has been fairly consistently timing out. When I asked the codeflow chat, they indicated that arm64 should be faster than x64 so it wasn't a machine issue and we should dig further. That's when we made them optional, later turned them off, and have been trying to find out why they are timing out ever since. Do you have a reason to believe the mac arm64 machines are slower than the x64 ones?
tmat commentedon Feb 13, 2025
No specific reason. I didn't know forgind is trying to figure out why. Just stating that we have been skipping the CI leg because it's been timing out.
Forgind commentedon Feb 26, 2025
@tmat, hit this again in #47110
Please fix this.
tmat commentedon Feb 26, 2025
This fixes a potential race condition: #47117
It looks like this race is hit by #47110 based on the test logs.
Forgind commentedon Apr 1, 2025
@tmat, hit this again in #48081
tmat commentedon Apr 1, 2025
@Forgind I don't see dotnet-watch failure in that PR.
Found this though: