Uh oh!
There was an error while loading. Please reload this page.
[wasm] Add disabled tests to ProjectExclusions - #65877
Conversation
ghost
commented
Feb 25, 2022
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)
| joinkind=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"
| summarizesum(Duration) cc @dotnet/runtime-infrastructure
|
radical
commented
Feb 25, 2022
We should probably then drop the cc @lewing |
ghost
commented
Feb 25, 2022
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)
| joinkind=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"
| summarizesum(Duration) cc @dotnet/runtime-infrastructure
|
elinor-fung
commented
Feb 25, 2022
The |
radical
commented
Feb 25, 2022
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