Open carlossanlop opened 1 year ago
Tagging subscribers to this area: @vitek-karas, @agocke, @vsadov See info in area-owners.md if you want to be subscribed.
Author: | carlossanlop |
---|---|
Assignees: | - |
Labels: | `area-Host` |
Milestone: | - |
The actual failure is:
System.UnauthorizedAccessException : Access to the path 'dotnet.exe' is denied.
at System.IO.FileSystem.RemoveDirectoryRecursive(String fullPath, WIN32_FIND_DATA& findData, Boolean topLevel)
at System.IO.FileSystem.RemoveDirectory(String fullPath, Boolean recursive)
at Microsoft.DotNet.CoreSetup.Test.HostActivation.MultilevelSDKLookup.Dispose() in /_/src/installer/tests/HostActivation.Tests/MultilevelSDKLookup.cs:line 87
at ReflectionAbstractionExtensions.DisposeTestClass(ITest test, Object testClass, IMessageBus messageBus, ExecutionTimer timer, CancellationTokenSource cancellationTokenSource) in /_/src/xunit.execution/Extensions/ReflectionAbstractionExtensions.cs:line 87
This looks a lot like robustness things we've been working on for a while and sort of solved in 7/8 where I don't remember seeing failures like this at all recently. I don't know if it's worth the effort to try to backport all of these test infra fixes.
Short version: I'm pretty sure this is not a product issue, but it's a test infra issue.
@elinor-fung who also worked on the test infra robustness for another opinion.
Yeah, this looks like test robustness issues we were chasing (and haven't seen recently) - not anything in the product. I'm also not sure if it is worth backporting the various fixes we've made, particularly since the failures are on cleanup, so by the time they are hit, the actual validation has been done/passed.
@carlossanlop if this starts happening in a lot in 6.0 PRs (hoping not based on the current hit count) and it slows you down too much, I can investigate what we would need to backport.
Tagging subscribers to this area: @hoyosjs See info in area-owners.md if you want to be subscribed.
Author: | carlossanlop |
---|---|
Assignees: | - |
Labels: | `arch-x86`, `os-windows`, `area-Infrastructure-coreclr`, `Known Build Error` |
Milestone: | - |
I didn't update the error blob, it's a bit too broad and will catch any error in the assembly. But the correct encoding was:
{
"BuildRetry": false,
"ErrorPattern": "Tests failed: .+\\\\HostActivation\\.Tests_net\\d\\.0_(x64|x86|arm64)+\\.html",
"ExcludeConsoleLog": false
}
@hoyosjs I changed the error blob to what you suggested.
Still seeing this failure. It was hit in this 6.0 PR: https://github.com/dotnet/runtime/pull/86295/
The error pattern seems to match all failures in the installer tests, e.g. this main PR https://github.com/dotnet/runtime/pull/85913/checks?check_run_id=13522623704 even though that fails with a different failure.
Sadly, multiline regex isn't supported to glob that it's hosting and comprises activation issues...
Ok let me revert the pattern and use x86 specifically. I'll create a new issue for the x64 one happening in main.
I updated the error pattern to reflect the specific UnauthorizedAccessException
that was being hit in 6.0.
The table in the description still has all the ones that were unintentionally linked before, but I think it should be filtered to what we want going forward.
@elinor-fung there's another hit in 6.0, specifically in the branding PR for 6.0.26: https://github.com/dotnet/runtime/pull/94482
Installer Build and Test coreclr windows_x86 Debug
Error message:
Known Issue Error Message
Fill the error message using known issues guidance.
Report
Summary
Known issue validation
Build: :mag_right: Result validation: :warning: Validation could not be done without an Azure DevOps build URL on the issue. Please add it to the "Build: :mag_right:" line.