-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Add VMR leg that builds test projects #44843
Conversation
Fixes dotnet/source-build#4168 Running as part of the PR to get some initial results.
@am11 did we see this one when we updated the VMR to the .NET 10 SDK? Can't remember if we talked about it. |
Yup, it was #43015 (comment). It will probably need a fix like dotnet/winforms@main...am11:winforms:patch-1. I'll try building it on windows soon. |
@am11 would you want to help me with driving this one in? I currently have some other obligations and won't be able to get back to this PR anytime soon. See the above efcore test failure. They need the same first class Span reaction update. There's also a winforms test failure in the PR that I don't really understand yet. |
I think #44922 is bringing winforms change. I'll check efcore. |
The efcore issue is weird:
The winforms failure is also still happening. |
Looks like a known bug dotnet/fsharp#17451. A solution (workaround?) is here dotnet/fsharp#11546 (comment). Since it is a test assembly perhaps we should just disable strong name signing? |
It would be interesting to understand why the fsharp test build behaves differently with the VMR. |
I'll try to set |
cc @mmitche as you approved the Arcade PR: dotnet/arcade#12940 and might have context here. |
I believe this should be conditioned on source-only or non-source only builds, rather than a blanket setting across all VMR builds. That said, I'm slightly uncomfortable with where the setting is put. I think it should actually be in StrongName.targets or generally within the arcade infra, rather than the source build control setup. |
I'll file an issue and open a PR to fix this. |
Tests build is failing in
I have not seen this locally and it is likely due to host configuration issues. I'm going to opt-out of building tests in |
Hmm, this PR is now hitting an odd error that I don't think is related. It's failure to restore vstest package during SDK repo build: I have not seen this in local build, but I have not refreshed the local sha in a week. I'm updating local sha to repro this. There were some recent changes in versioning i.e. the use of official or dev labels. @ViktorHofer @mmitche does this sound familiar? I'm not sure which repo builds |
That looks like a new package dependency that is not being built. It's built out of vstest normally: https://github.com/microsoft/vstest/blob/main/src/package/Microsoft.TestPlatform.TestHost/Microsoft.TestPlatform.TestHost.csproj#L7-L8 |
@NikolaMilosavljevic vstest just doesn't build on non-Windows. I'm updating the conditional to pack on Windows too, but we should disable building the test on non-Windows. |
|
This looks different. it looks like an SDK test project, that is referencing a vstest package that is not produced on Linux. |
I see - there are 60+ I'll create a tracking issue in source-build. |
I've merged the latest from |
First successful build of the '_BuildTests' leg - it took 106 minutes. @ViktorHofer We are skipping tests in several repos, i.e. There is a failure in repo's test leg, which is unrelated. |
@NikolaMilosavljevic changes LGTM |
@mmitche @MichaelSimons @marcpopMSFT can someone merge this? I don't have permissions. |
Fixes dotnet/source-build#4168
Running as part of the PR to get some initial results.