Skip to content
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

Make SmokeTests use repo infrastructure #19290

Merged
merged 79 commits into from
Apr 9, 2024
Merged

Make SmokeTests use repo infrastructure #19290

merged 79 commits into from
Apr 9, 2024

Conversation

ViktorHofer
Copy link
Member

@ViktorHofer ViktorHofer commented Apr 3, 2024

Fixes dotnet/source-build#3615
Fixes dotnet/source-build#4289

This allows the test project to just be invoked with dotnet test or dotnet build /t:Test. Running the UnifiedBuild test projects requires the VMR to first be built to have access to the live built SDK but that's already the case.

  1. Stop depending on environment variables for state instead use RuntimeConfiguration values same as UnifiedBuild test project. Allow facts and theories to be conditioned based on boolean values instead of env vars.
  2. Update the README with the new msbuild property switch names
  3. Delete dead-code and the checked-in .sln file
  4. Update YMLs
  5. Update build scripts to call into the Test target instead.
  6. Use the Microsoft.Build.Traversal SDK inside build.proj
  7. Borrow some of the script changes from Enable scenario test execution in VMR build #19222 to be able to invoke tests to build and test them or just test them.

This allows the test project to just be invoked with
`dotnet test` or `dotnet build /t:Test` after the
VMR is built.

1. Stop depending on environment variables for state
   instead use RuntimeConfiguration values same
   as UnifiedBuild test project. Allow facts and
   theories to be conditioned based on boolean
   values instead of env vars.
2. Update the README with the new msbuild property
   switch names
3. Delete dead-code and the checked-in .sln file
@ViktorHofer
Copy link
Member Author

ViktorHofer commented Apr 8, 2024

Found an AFAICT unintended breaking change in the FileSytemGlobbing API between 8.0.0 and 9.0 Preview 1 and filed an issue for it: dotnet/runtime#100762

I worked around it by downgrading the packages to 8.0.0.

cc @jozkee @jeffhandley

@ViktorHofer
Copy link
Member Author

ViktorHofer commented Apr 8, 2024

Validation builds:

Summary:

  • The dotnet-source-build internal full build has a lot of red but the red is identical with the latest scheduled/rolling build. The legs that pass run the smoke tests as expected and they succeed.
  • The license scan tests run as expected and succeed.
  • The SDK diff tests don't run because it can't find a corresponding installer build. That seems to be related to the manual vmr-sync. Given the already exhaustive testing that I performed, I would say let's merge this in and I will monitor the next build and respond to any potential regressions. Note that I locally ran these tests and they succeeded.
  • The poison tests run as expected and report the following (AFAIK known) poison leaks:
<PrebuiltLeakReport>
  <File Path="artifacts/assets/Release/dotnet-sdk-x.y.z/sdk/x.y.z/DotnetTools/dotnet-format/Microsoft.CodeAnalysis.AnalyzerUtilities.dll">
    <Type>AssemblyAttribute</Type>
  </File>
  <File Path="artifacts/assets/Release/dotnet-sdk-x.y.z/sdk/x.y.z/DotnetTools/dotnet-watch/x.y.z/tools/netx.y/any/Microsoft.CodeAnalysis.AnalyzerUtilities.dll">
    <Type>AssemblyAttribute</Type>
  </File>
  <File Path="artifacts/assets/Release/dotnet-sdk-x.y.z/sdk/x.y.z/Sdks/Microsoft.NET.Sdk/analyzers/cs/Microsoft.CodeAnalysis.NetAnalyzers.resources.dll">
    <Type>AssemblyAttribute</Type>
  </File>
  <File Path="artifacts/assets/Release/dotnet-sdk-x.y.z/sdk/x.y.z/Sdks/Microsoft.NET.Sdk/analyzers/de/Microsoft.CodeAnalysis.NetAnalyzers.resources.dll">
    <Type>AssemblyAttribute</Type>
  </File>
  <File Path="artifacts/assets/Release/dotnet-sdk-x.y.z/sdk/x.y.z/Sdks/Microsoft.NET.Sdk/analyzers/es/Microsoft.CodeAnalysis.NetAnalyzers.resources.dll">
    <Type>AssemblyAttribute</Type>
  </File>
  <File Path="artifacts/assets/Release/dotnet-sdk-x.y.z/sdk/x.y.z/Sdks/Microsoft.NET.Sdk/analyzers/fr/Microsoft.CodeAnalysis.NetAnalyzers.resources.dll">
    <Type>AssemblyAttribute</Type>
  </File>
  <File Path="artifacts/assets/Release/dotnet-sdk-x.y.z/sdk/x.y.z/Sdks/Microsoft.NET.Sdk/analyzers/it/Microsoft.CodeAnalysis.NetAnalyzers.resources.dll">
    <Type>AssemblyAttribute</Type>
  </File>
  <File Path="artifacts/assets/Release/dotnet-sdk-x.y.z/sdk/x.y.z/Sdks/Microsoft.NET.Sdk/analyzers/ja/Microsoft.CodeAnalysis.NetAnalyzers.resources.dll">
    <Type>AssemblyAttribute</Type>
  </File>
  <File Path="artifacts/assets/Release/dotnet-sdk-x.y.z/sdk/x.y.z/Sdks/Microsoft.NET.Sdk/analyzers/ko/Microsoft.CodeAnalysis.NetAnalyzers.resources.dll">
    <Type>AssemblyAttribute</Type>
  </File>
  <File Path="artifacts/assets/Release/dotnet-sdk-x.y.z/sdk/x.y.z/Sdks/Microsoft.NET.Sdk/analyzers/Microsoft.CodeAnalysis.CSharp.NetAnalyzers.dll">
    <Type>AssemblyAttribute</Type>
  </File>
  <File Path="artifacts/assets/Release/dotnet-sdk-x.y.z/sdk/x.y.z/Sdks/Microsoft.NET.Sdk/analyzers/Microsoft.CodeAnalysis.NetAnalyzers.dll">
    <Type>AssemblyAttribute</Type>
  </File>
  <File Path="artifacts/assets/Release/dotnet-sdk-x.y.z/sdk/x.y.z/Sdks/Microsoft.NET.Sdk/analyzers/Microsoft.CodeAnalysis.VisualBasic.NetAnalyzers.dll">
    <Type>AssemblyAttribute</Type>
  </File>
  <File Path="artifacts/assets/Release/dotnet-sdk-x.y.z/sdk/x.y.z/Sdks/Microsoft.NET.Sdk/analyzers/pl/Microsoft.CodeAnalysis.NetAnalyzers.resources.dll">
    <Type>AssemblyAttribute</Type>
  </File>
  <File Path="artifacts/assets/Release/dotnet-sdk-x.y.z/sdk/x.y.z/Sdks/Microsoft.NET.Sdk/analyzers/pt-BR/Microsoft.CodeAnalysis.NetAnalyzers.resources.dll">
    <Type>AssemblyAttribute</Type>
  </File>
  <File Path="artifacts/assets/Release/dotnet-sdk-x.y.z/sdk/x.y.z/Sdks/Microsoft.NET.Sdk/analyzers/ru/Microsoft.CodeAnalysis.NetAnalyzers.resources.dll">
    <Type>AssemblyAttribute</Type>
  </File>
  <File Path="artifacts/assets/Release/dotnet-sdk-x.y.z/sdk/x.y.z/Sdks/Microsoft.NET.Sdk/analyzers/tr/Microsoft.CodeAnalysis.NetAnalyzers.resources.dll">
    <Type>AssemblyAttribute</Type>
  </File>
  <File Path="artifacts/assets/Release/dotnet-sdk-x.y.z/sdk/x.y.z/Sdks/Microsoft.NET.Sdk/analyzers/zh-Hans/Microsoft.CodeAnalysis.NetAnalyzers.resources.dll">
    <Type>AssemblyAttribute</Type>
  </File>
  <File Path="artifacts/assets/Release/dotnet-sdk-x.y.z/sdk/x.y.z/Sdks/Microsoft.NET.Sdk/analyzers/zh-Hant/Microsoft.CodeAnalysis.NetAnalyzers.resources.dll">
    <Type>AssemblyAttribute</Type>
  </File>
</PrebuiltLeakReport>

@ViktorHofer ViktorHofer enabled auto-merge (squash) April 8, 2024 14:11
@mthalman mthalman disabled auto-merge April 8, 2024 16:06
Copy link
Member

@mthalman mthalman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the future, consider breaking up changes like this into separate PRs to allow for more focused reviews. I feel like this could have easily been 3 separate PRs or even more.

@@ -15,6 +15,7 @@
</ItemGroup>

<ItemGroup>
<EnvironmentVariables Include="NUGET_PACKAGES=$(NuGetPackageRoot)" />
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does this have to do with test infrastructure?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Before, we globally set NUGET_PACKAGES but we don't do that anymore so that we can have a separate nuget package cache for the VMR tests. Nuget-client is the only repo that doesn't respect the NUGET_PACKAGES env var that is provided by Arcade because they don't use Arcade: https://github.com/dotnet/arcade/blob/f54c598d137ab88bd473ea670b3c751be0540244/src/Microsoft.DotNet.Arcade.Sdk/tools/SourceBuild/SourceBuildArcadeBuild.targets#L90

I filed dotnet/source-build#4293 which is relevant here. nuget-client incorrectly uses the VMR package cache (already in main).

@ellahathaway
Copy link
Member

ellahathaway commented Apr 8, 2024

In your PR description, you mention that we can use dotnet test to invoke the tests. I tried just now to invoke the tests via .dotnet/dotnet test src/SourceBuild/content/test/Microsoft.DotNet.SourceBuild.SmokeTests/ from the installer repo, but it failed with this error:

/workspaces/installer/src/SourceBuild/content/test/Microsoft.DotNet.SourceBuild.SmokeTests/DotNetHelper.cs(38): error VSTEST1: (Microsoft.DotNet.SourceBuild.SmokeTests.SourcelinkTests.VerifySourcelinks) Microsoft.DotNet.SourceBuild.SmokeTests.DotNetHelper..ctor(ITestOutputHelper outputHelper) System.InvalidOperationException : Tarball path '' specified in  does not exist.

I was under the impression that the Sdk tarball path had a default (added by your changes). Can you explain why that default was not set properly when I invoked the tests in this way? Is it because the default is looking for a built SDK in the artifacts? If that's the case, I'd rather this not be the failing exception. Rather, the failure should happen when the tarball path variable is originally set in my opinion.

@ViktorHofer
Copy link
Member Author

ViktorHofer commented Apr 8, 2024

I was under the impression that the Sdk tarball path had a default (added by your changes). Can you explain why that default was not set properly when I invoked the tests in this way?

Yes, when you build the repo from within the VMR, the Sdk tarball has its default value. The resolution logic depends on this target:

<Target Name="DetermineSourceBuiltSdkVersion">
which relies on installer produced packages. If you want to execute a test that depends on the live built SDK, you either need to build the VMR first or supply the SDK via the /p:SdkTarballPath property. Please let me know if this scenario worked before but is now regressed. I don't think that's the case.

What I meant is that you can now test the smoke tests project directly with dotnet test but you need to filter down the test that you want to execute and/or supply all the required inputs.

@ViktorHofer
Copy link
Member Author

In the future, consider breaking up changes like this into separate PRs to allow for more focused reviews. I feel like this could have easily been 3 separate PRs or even more.

When you look at the commits you will noticed that I originally started just with the bare minimum number of changes and then only added to those because the build required those. This organically grew from ~20 to 50 file changes. If you feel that separating these changes into individual PRs is a good investment of time then I can try that but it will be hard because many of these are intertangled.

@mthalman
Copy link
Member

mthalman commented Apr 8, 2024

In the future, consider breaking up changes like this into separate PRs to allow for more focused reviews. I feel like this could have easily been 3 separate PRs or even more.

When you look at the commits you will noticed that I originally started just with the bare minimum number of changes and then only added to those because the build required those. This organically grew from ~20 to 50 file changes. If you feel that separating these changes into individual PRs is a good investment of time then I can try that but it will be hard because many of these are intertangled.

No, not necessary to break up this PR at this point.

@MichaelSimons
Copy link
Member

Looks like there are still compilation errors:

/vmr/test/Microsoft.DotNet.SourceBuild.SmokeTests/OmniSharpTests.cs(30,6): error CS0246: The type or namespace name 'ConditionalTheoryAttributeAttribute' could not be found (are you missing a using directive or an assembly reference?) [/vmr/test/Microsoft.DotNet.SourceBuild.SmokeTests/Microsoft.DotNet.SourceBuild.SmokeTests.csproj]
/vmr/test/Microsoft.DotNet.SourceBuild.SmokeTests/OmniSharpTests.cs(30,6): error CS0246: The type or namespace name 'ConditionalTheoryAttribute' could not be found (are you missing a using directive or an assembly reference?) [/vmr/test/Microsoft.DotNet.SourceBuild.SmokeTests/Microsoft.DotNet.SourceBuild.SmokeTests.csproj]

@ViktorHofer
Copy link
Member Author

Ooops, forgot to build everything. That's now fixed.

@ViktorHofer ViktorHofer merged commit be917a9 into main Apr 9, 2024
22 checks passed
@ViktorHofer ViktorHofer deleted the RefactorSmokeTests branch April 9, 2024 05:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

VMR smoke test project hardcodes package versions and TFM Increase clarity in test case skipping
4 participants