-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
[wasm] Run Wasm.Build.Tests
against workloads
#54451
Conversation
3a62ae1
to
81373d9
Compare
6d43522
to
9165c39
Compare
Wasm.Build.Tests
against workload
Tagging subscribers to 'arch-wasm': @lewing Issue DetailsCurrently we run For this:
The specified SDK is installed in
Once this setup is done, then the tests are run in an environment such that they use Known issues:
We still want to test without packs, the case of using Tests:
Notes:
|
cc @lewing @steveisok @radekdoulik @akoeplinger RFC! |
Wasm.Build.Tests
against workloadWasm.Build.Tests
against workloads
<Project> | ||
<PropertyGroup> | ||
<WasmNativeWorkload>true</WasmNativeWorkload> | ||
<UseMonoRuntime>true</UseMonoRuntime> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file is always included once the workload is installed, you should stick any new properties in a conditionally included group.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But the right place to still all these is in Sdk.props I think
src/mono/nuget/Microsoft.NET.Runtime.WebAssembly.Sdk/Sdk/AutoImport.props.in
Outdated
Show resolved
Hide resolved
src/mono/nuget/Microsoft.NET.Workload.Mono.Toolchain.Manifest/WorkloadManifest.targets.in
Outdated
Show resolved
Hide resolved
d42f53c
to
b7dfd99
Compare
9326d56
to
76cd866
Compare
Just doing some final tidbits, but this should be good for reviewing. |
da822a5
to
6ca6281
Compare
/azp run |
You have several pipelines (over 10) configured to build pull requests in this repository. Specify which pipelines you would like to run by using /azp run [pipelines] command. You can specify multiple pipelines using a comma separated list. |
/azp run runtime,runtime-staging |
Azure Pipelines successfully started running 2 pipeline(s). |
b73db09
to
df94014
Compare
@@ -1,4 +1,8 @@ | |||
<Project> | |||
<PropertyGroup> | |||
<UseMonoRuntime Condition="'$(RuntimeIdentifier)' == 'Browser-wasm'">true</UseMonoRuntime> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think/hope this is no longer needed after my #55258
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your PR changes the InTree, and LocalBuild targets, which don't get used for the workloads.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we could move it to an Sdk.props in the WebAssembly sdk though, that way it will only get picked up when that workload is in use.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Follow up PR? :) And if we are moving it to wasm sdk, then might as well move it to wasm props, then it won't be needed in InTree/LocalBuild either.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Discussed some follow up with @radical but since we're already have a pending pr building off this the changes can happen there
That will be handled in dotnet#54451
* [wasm] Run browser tests on helix/windows * Build just wasm/browsertests on helix/windows * Use $(ChromiumRevision) in windows links * Fix conditions * Set PATH differently * Use backslash in PATH on windows * Try different version of chromium * Pass scenario and browser host to build And set browser path on windows to be able to start chrome from xharness * Try to get more info from the helix workitems * Fix dir separator, add broser path * Create WasmBuildSupportDir * Revert "Try to get more info from the helix workitems" This reverts commit 8807434. * Put the dir cmds back, fix mkdir call * More debug info * Bump xharness * Bump xharness again With darc this time * StressLogAnalyzer didn't print the number of messages correctly if it exceeded the int range (2 billion). (#54832) Fix is to just use 64 bit ints instead. * Found a race condition where the LOH flag on a segment is set too late. This gives another thread the chance to allocate in a fresh LOH region that doesn't have the LOH flag set just yet and trip over an assert in Object::ValidateInner. (#54839) The fix is simply to set the flag in get_new_region before the region is put on the list for the LOH generation. * Try to show the chrome logs * Use different path for chrome logs * Use newer image with font for chrome The chrome was crashing, because it didn't find any sans-serif font. * Increase timeouts * Disable tests which timeout * Remove debug calls * Put back normal scenario * Do not set scenario in build args * Add browser sample exclusion * Restore the platform matrix * Remove the wasm build test changes That will be handled in #54451 * Remove duplicate exclusion * Suggested property name change * Fix last merge * Simplify condition We don't pass Scenario anymore * Include chrome and chromedriver in the payload Co-authored-by: Peter Sollich <petersol@microsoft.com>
Currently we run
Wasm.Build.Tests
on helix, by setting various paths to reference files fromartifacts
. This PR adds another mode, we try to test against workload packs.For this:
Steps:
artifacts/bin/dotnet-workload
depends-on
manifests in the json.dotnet workload install
is used to install the packs, with the built nugets path being used as one the nuget sourcsOnce this setup is done, then the tests are run in an environment such that they use
dotnet
from above, and try to resolve packs from there.We still want to test without packs, the case of using
EMSDK_PATH
directly, for example, in the library tests. So, we now runWasm.Build.Tests
for Workloads, and the regularEMSDK_PATH
.Two workload specific tests were added in a recent PR ([wasm] Update Wasm.Build.Tests to build with net6.0 #54936)
simple test for building blazorwasm template project with AOT
a test to validate that the files in
UnixFilePermissions.xml
for the packs actually exist on disk.. and these are enabled here.
TestUsingWorkloads=true
, and specifies the workload with:Notes:
<SdkVersionForWorkloadTesting>6.0.100-preview.7.21326.4</SdkVersionForWorkloadTesting>
ineng/Versions.props
Pack
on the aotcross pkgprojTODO: