[wasm] Add disabled tests to ProjectExclusions #65877
Conversation
ghost
assigned 
|
Tagging subscribers to this area: @dotnet/area-infrastructure-libraries Issue Details
They are actually disabled for all mono, but we don't have a mechanism in place of avoiding the build, work item queuing, test discovery, result upload, and such for desktop Mono (since we build libraries tests once and use them for coreclr and non-device mono test runs). The wasm ones were the most time-intensive due to AOT-ing on the helix machine. Based on the below query, in the past two days, running those two tests suites (neither of which actually run any tests) for wasm has taken about 6.75 days of various machines' time. WorkItems
| where Started > ago(2d)
| join kind=inner Jobs on JobId
| where FriendlyName endswith "System.ComponentModel.Composition.Tests"
or FriendlyName endswith "Microsoft.Extensions.Caching.Memory.Tests"
| project
FriendlyName,
Queued, Started, Finished,
Duration = Finished - Started,
QueueName,
Pipeline = tostring(parse_json(Properties).DefinitionName),
PhaseName = tostring(parse_json(Properties)["System.PhaseName"]),
Runtime = tostring(parse_json(Properties).runtimeFlavor),
ConsoleUri,
Source
| where Runtime == "mono"
| where PhaseName contains "Browser"
| summarize sum(Duration) cc @dotnet/runtime-infrastructure
|
|
We should probably then drop the cc @lewing |
|
Tagging subscribers to 'arch-wasm': @lewing Issue Details
They are actually disabled for all mono, but we don't have a mechanism in place of avoiding the build, work item queuing, test discovery, result upload, and such for desktop Mono (since we build libraries tests once and use them for coreclr and non-device mono test runs). The wasm ones were the most time-intensive due to AOT-ing on the helix machine. Based on the below query, in the past two days, running those two tests suites (neither of which actually run any tests) for wasm has taken about 6.75 days of various machines' time. WorkItems
| where Started > ago(2d)
| join kind=inner Jobs on JobId
| where FriendlyName endswith "System.ComponentModel.Composition.Tests"
or FriendlyName endswith "Microsoft.Extensions.Caching.Memory.Tests"
| project
FriendlyName,
Queued, Started, Finished,
Duration = Finished - Started,
QueueName,
Pipeline = tostring(parse_json(Properties).DefinitionName),
PhaseName = tostring(parse_json(Properties)["System.PhaseName"]),
Runtime = tostring(parse_json(Properties).runtimeFlavor),
ConsoleUri,
Source
| where Runtime == "mono"
| where PhaseName contains "Browser"
| summarize sum(Duration) cc @dotnet/runtime-infrastructure
|
|
The |
|
Oh, sorry, I misunderstood! nit: add a comment in the proj file that they are also disabled in the source. |
Microsoft.Extensions.Caching.Memory.TestsandSystem.ComponentModel.Composition.Testsare already disabled via assembly-level attributes in source.runtime/src/libraries/Microsoft.Extensions.Caching.Memory/tests/AssemblyAttributes.cs
Line 6 in c32b1f5
runtime/src/libraries/System.ComponentModel.Composition/tests/AssemblyInfo.cs
Line 6 in c32b1f5
They are actually disabled for all mono, but we don't have a mechanism in place of avoiding the build, work item queuing, test discovery, result upload, and such for desktop Mono (since we build libraries tests once and use them for coreclr and non-device mono test runs). The wasm ones were the most time-intensive due to AOT-ing on the helix machine.
Based on the below query, in the past two days, running those two tests suites (neither of which actually run any tests) for wasm has taken about 6.75 days of various machines' time.
cc @dotnet/runtime-infrastructure