[wasm] Move EnableAggressiveTrimming build to runtime pipeline

[radical]

.. from runtime-staging, so any changes that break that can be caught,
and fixed. Any test failures in runtime-staging don't fail the job
itself, so it gets missed.

[ghost]

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

.. from runtime-staging, so any changes that break that can be caught,
and fixed. Any test failures in runtime-staging don't fail the job
itself, so it gets missed.

Author:	radical
Assignees:	-
Labels:	arch-wasm, trimming-for-aot
Milestone:	-

[radical]

This will need a fix for #52194 (comment) which @eerhardt is looking at, to get a green build.

[steveisok]

The work items on this leg have had a > 90% pass rate for at least the last 14 days.

[lewing]

based on the new lanes failing in #52194 (comment) that is probably trimming related?

[ViktorHofer]

Is this just about building or also testing on helix? If the former then there's no need to move it over from runtime-staging as in case of build errors, the legs turns red and marks the PR as failed. Only test failures in the runtime-staging leg are ignored in the PR's success mark.

[radical]

Tests are built for AOT (in runtime-staging), and those have to use EnableAggressiveTrimming(EAT). To make sure that the AOT test run doesn't fail because of EAT failures, we use a separate job for just building tests with EAT. This is that job.

We need to keep this job green, and since it can break with any library change, we want it to be in runtime, so it can get caught+fixed at the time of the change.

[radical]

Err.. sorry, I misspoke. For the EAT job, we do build and run the tests. This ensures that the tests pass with trimming.

And the AOT job in runtime-staging runs the same set of tests as above.

[ViktorHofer]

Cool. What's the current pass rate of these tests in runtime-staging? We usually move stuff over when they reach 80-90% pass rate.

[radical]

According to @steveisok:

The work items on this leg have had a > 90% pass rate for at least the last 14 days.

[ViktorHofer]

Great 👍 thanks a lot

[eerhardt]

This will need a fix for #52194 (comment) which @eerhardt is looking at, to get a green build.

#52265 should address the wasm EAT test failures in Microsoft.Extensions.HostFactoryResolver.Tests.

[lewing]

runtime (Build Browser wasm Release AllSubsets_Mono) failure is #51131

Please see https://chromedriver.chromium.org/security-considerations for suggestions on keeping ChromeDriver safe.
ChromeDriver was started successfully.
[03:49:29] info: browser: Console websocket connected.
[03:49:29] info: Arguments: --run,WasmTestRunner.dll,System.Data.Common.Tests.dll,-notrait,category=IgnoreForCI,-notrait,category=OuterLoop,-notrait,category=failing
[03:49:31] info: Initializing.....
[03:50:07] info: Discovering: System.Data.Common.Tests.dll (method display = ClassAndMethod, method display options = None)
[03:50:07] info: Discovered:  System.Data.Common.Tests.dll (found 1787 of 1813 test cases)
[03:50:07] info: Starting:    System.Data.Common.Tests.dll
[03:50:07] fail: [FAIL] System.Data.Tests.AppDomainsAndFormatInfo.Bug55978
[03:50:07] info: Assert.Equal() Failure
[03:50:07] info: Expected: 2
[03:50:07] info: Actual:   3
[03:50:07] info:    at System.Data.Tests.AppDomainsAndFormatInfo.Bug55978()
[03:50:07] info:    at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
[03:50:07] info: Finished:    System.Data.Common.Tests.dll
[03:50:07] info: 
[03:50:07] info: === TEST EXECUTION SUMMARY ===
[03:50:07] info: Total: 11692, Errors: 0, Failed: 1, Skipped: 10, Time: 27.68769s
[03:50:07] info: