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

Shift Most of Wasm AOT test build to helix #48226

Merged
merged 128 commits into from
Apr 22, 2021

Conversation

steveisok
Copy link
Member

@steveisok steveisok commented Feb 12, 2021

Since AOT'ing each test suite takes between 3-9 min, we need to shift the burden over to helix.

This is done by:

  1. building the test assemblies on the build machine
    • the wasm part of the build is not executed on the build machine,
      because it has the AOT build part
  2. Zip up the test assembly+friends, and any bits required to run the wasm
    app build for that on helix (eg. emsdk, wasm app targets, cross compiler etc)
  3. Send all this to helix, and use a custom aot-build.proj
    • which recreates all the build inputs for the WasmBuildApp target
      using the paths for the assets on helix
    • then we can run WasmBuildApp for the build, resulting in a wasm app
      bundle.
  4. Run the tests!
  • We already have the bits required for building wasm apps on helix, supported
    for Wasm.Build.Tests, which we can use here too.

Trimming:

  • Since, AOT can be so expensive, we use EnableAggressiveTrimming=true(EAT), but
    that means that we could have issues due to trimming.

  • And it can sometimes be unclear whether the build/test failures are due to trimming
    or AOT.

  • Because these builds+test runs are different from other builds, owing to the
    "build partially on helix" step, a normal EAT build would not be the same as

  • to help with testing this, we add two lanes to runtime-staging:

    • *_Mono_AOT: builds AOT+EAT on helix
    • *_Mono_EAT: builds EAT, on helix
      • this is required because we want to run almost the same kinda
        build: 1. build test assembly; 2. send to helix; 3. build wasm app; 4. run tests
  • This should effectively mean that we can see which errors might be due to EAT, and
    which are clearly because of EAT+AOT.

@ghost
Copy link

ghost commented Feb 12, 2021

Tagging subscribers to this area: @directhex
See info in area-owners.md if you want to be subscribed.

Issue Details

Since AOT'ing each test suite takes between 3-9 min, we need to shift the burden over to helix.

Author: steveisok
Assignees: -
Labels:

area-Infrastructure-mono

Milestone: -

Base automatically changed from master to main March 1, 2021 09:07
Comment on lines 50 to 58
<PropertyGroup Condition="'$(UseDefaultBlazorWASMFeatureSwitches)' == 'true'">
<EventSourceSupport>false</EventSourceSupport>
<UseSystemResourceKeys>true</UseSystemResourceKeys>
<UseSystemResourceKeys>false</UseSystemResourceKeys>
<EnableUnsafeUTF7Encoding>false</EnableUnsafeUTF7Encoding>
<HttpActivityPropagationSupport>false</HttpActivityPropagationSupport>

<!-- we want to default to what Blazor has, except if we are building in Debug config -->
<DebuggerSupport Condition="'$(Configuration)' != 'Debug'">false</DebuggerSupport>
<DebuggerSupport Condition="'$(DebuggerSupport)' == '' and '$(Configuration)' != 'Debug'">false</DebuggerSupport>
</PropertyGroup>
Copy link
Member

Choose a reason for hiding this comment

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

Some these need to have values different from what UseDefaultBlazorWasmFeatureSwitches wants:

  • DebuggerSupport - this is needed by some library tests because they depend on pdbs, or debugger attributes
    • Currently, I am setting this in the specific projects that need it
  • UseSystemResourceKeys - IIUC, this is needed so that the resources don't get trimmed, which is needed by some library tests

Setting these only for some library projects makes it kinda inconsistent. And I'm wondering if that affects what the intention of UseDefaultBlazorWasmFeatureSwitches is.
So, do we need switch at all? If so, then what should be done here?

/cc @lewing @akoeplinger

Copy link
Member

Choose a reason for hiding this comment

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

I agree with @radical, the intention of UseDefaultBlazorWASMFeatureSwitches is to make us consistent with Blazor. I think overriding in the individual library test projects where necessary is fine for now.

@@ -219,7 +219,7 @@ jobs:
targetRid: browser-wasm
platform: Browser_wasm
container:
image: ubuntu-18.04-webassembly-20210223133559-4800846
image: ubuntu-18.04-webassembly-20210309143118-005aab4
Copy link
Member

Choose a reason for hiding this comment

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

@steveisok @mdh1418 Do you know why this change was made? main is still using the older version.

Copy link
Member

Choose a reason for hiding this comment

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

judging from the date it's to bring in dotnet/dotnet-buildtools-prereqs-docker@f25f6cd

…LoadContext

The test project explicitly copies, and needs `mscorlib.dll`, which gets
trimmed out with `EnableAggressiveTrimming=true`. Preserve that.
Fails because it can't find `xunit.runner.utility.netcoreapp10`
`InlineDataDiscoverer`, and `MemberDataDiscoverer` were getting
trimmed, which would cause some tests to get skipped. For example, ~9k
tests in `System.Data.Common.Tests`
@radical
Copy link
Member

radical commented Apr 21, 2021

Failing test in runtime (Libraries Test Run release mono Linux x64 Debug): #51588

Failing test in Libraries Test Run release coreclr Linux x64 Debug is possibly: #48658

Failing test in Libraries Test Run release mono OSX x64 Debug: #51611

@@ -219,7 +219,7 @@ jobs:
targetRid: browser-wasm
platform: Browser_wasm
container:
image: ubuntu-18.04-webassembly-20210223133559-4800846
image: ubuntu-18.04-webassembly-20210309143118-005aab4
Copy link
Member

Choose a reason for hiding this comment

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

judging from the date it's to bring in dotnet/dotnet-buildtools-prereqs-docker@f25f6cd

Comment on lines 50 to 58
<PropertyGroup Condition="'$(UseDefaultBlazorWASMFeatureSwitches)' == 'true'">
<EventSourceSupport>false</EventSourceSupport>
<UseSystemResourceKeys>true</UseSystemResourceKeys>
<UseSystemResourceKeys>false</UseSystemResourceKeys>
<EnableUnsafeUTF7Encoding>false</EnableUnsafeUTF7Encoding>
<HttpActivityPropagationSupport>false</HttpActivityPropagationSupport>

<!-- we want to default to what Blazor has, except if we are building in Debug config -->
<DebuggerSupport Condition="'$(Configuration)' != 'Debug'">false</DebuggerSupport>
<DebuggerSupport Condition="'$(DebuggerSupport)' == '' and '$(Configuration)' != 'Debug'">false</DebuggerSupport>
</PropertyGroup>
Copy link
Member

Choose a reason for hiding this comment

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

I agree with @radical, the intention of UseDefaultBlazorWASMFeatureSwitches is to make us consistent with Blazor. I think overriding in the individual library test projects where necessary is fine for now.

</ItemGroup>

<!-- To recreate the original project on helix, we need to set the wasm properties also, same as the
library test project. Eg. $(InvariantGlobalization) -->
Copy link
Member

@akoeplinger akoeplinger Apr 21, 2021

Choose a reason for hiding this comment

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

do we have a way of knowing the list of properties is complete or when we need to update it?

Copy link
Member

Choose a reason for hiding this comment

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

Um .. not really. So, when something breaks? I didn't add all the properties either, because I want to do that as it comes up.

@@ -2,6 +2,7 @@
<PropertyGroup>
<IncludeRemoteExecutor>true</IncludeRemoteExecutor>
<TargetFrameworks>$(NetCoreAppCurrent)</TargetFrameworks>
<DebuggerSupport Condition="'$(DebuggerSupport)' == '' and '$(TargetOS)' == 'Browser'">true</DebuggerSupport>
Copy link
Member

Choose a reason for hiding this comment

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

curious why does this need .pdb?

Copy link
Member

Choose a reason for hiding this comment

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

Eg:

  fail: [FAIL] System.Collections.Tests.HashtableTests.DebuggerAttribute
  info: System.InvalidOperationException : Expected one DebuggerDisplayAttribute on System.Collections.Hashtable.
  info:    at System.Diagnostics.DebuggerAttributes.ValidateDebuggerDisplayReferences(Object obj)
  info:    at System.Collections.Tests.HashtableTests.DebuggerAttribute()
  info:    at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)

 fail: [FAIL] System.Collections.Tests.QueueTests.DebuggerAttribute_NullQueue_ThrowsArgumentNullException
  info: System.InvalidOperationException : Expected one DebuggerTypeProxyAttribute on System.Collections.Queue.
  info:    at System.Diagnostics.DebuggerAttributes.GetProxyType(Type type, Type[] genericTypeArguments)
  info:    at System.Diagnostics.DebuggerAttributes.ValidateDebuggerTypeProxyProperties(Type type, Type[] genericTypeArguments, Object obj)
  info:    at System.Diagnostics.DebuggerAttributes.ValidateDebuggerTypeProxyProperties(Type type, Object obj)
  info:    at System.Collections.Tests.QueueTests.DebuggerAttribute_NullQueue_ThrowsArgumentNullException()
  info:    at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)

@@ -0,0 +1,55 @@
// Licensed to the .NET Foundation under one or more agreements.
Copy link
Member

Choose a reason for hiding this comment

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

this should ideally be added to

<ProjectReference Remove="$(MSBuildThisFileDirectory)WasmAppBuilder\WasmAppBuilder.csproj"
Condition="'$(TargetOS)' != 'Browser'" />
<ProjectReference Remove="$(MSBuildThisFileDirectory)WasmBuildTasks\WasmBuildTasks.csproj"
Condition="'$(TargetOS)' != 'Browser'" />

Copy link
Member

Choose a reason for hiding this comment

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

I'm not sure I understand. This file will get built with WasmBuildTasks. What should be added to tasks.proj?

Copy link
Member

@lewing lewing left a comment

Choose a reason for hiding this comment

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

looks green to me, there is some minor whitespace damage but this was a long road so lets land it.

@radical radical merged commit 6ca3d91 into dotnet:main Apr 22, 2021
@karelz karelz added this to the 6.0.0 milestone May 20, 2021
@ghost ghost locked as resolved and limited conversation to collaborators Jun 19, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants