Reduce Mono/WASM PR pipeline jobs on library and non-mono changes

[davidwrighton]

Note

This PR was generated with the assistance of GitHub Copilot.

Summary

Reduce the number of helix jobs and work items submitted for PR builds that don't touch mono or WASM code. Based on analysis of the last 100 builds on the runtime pipeline, ~33% of PRs are library or infrastructure changes that were triggering unnecessary mono/WASM work.

Changes

1. browser_wasm_win Mono library tests → smoke-only on library changes

Added shouldRunSmokeOnly: onLibrariesAndIllinkChanges to the browser_wasm_win Mono WASM library test. When only libraries or illink paths change (no WASM-specific changes), this runs ~4 smoke test projects instead of the full ~60+ test assemblies.

The browser_wasm (Linux, Chrome) Mono test remains a full run, ensuring at least 1 complete Mono WASM validation per library PR.

2. Mono Android removed from library/installer PR triggering

Removed libraries.containsChange and installer.containsChange from the Mono Android (android_arm, android_arm64) job condition. Android is moving to CoreCLR-only for customers, so Mono Android PR validation on library changes is no longer needed.

• Still runs when mono code explicitly changes (mono_excluding_wasm.containsChange)
• Still runs on rolling/CI builds (twice daily)
• CoreCLR Android (android_x64, android_arm64) is unchanged and continues providing Android PR coverage

3. Mono MiniJIT Library Tests reduced to 1 platform on library PRs

Split the Mono_MiniJIT_LibrariesTests job into two blocks:

• linux_arm64: runs on library changes, mono changes, and rolling builds
• linux_x64 + osx_x64: runs only on mono changes and rolling builds

When mono code explicitly changes, all 3 platforms still run.

4. Removed Firefox from Mono WASM full run

The browser_wasm Mono library test previously ran both WasmTestOnChrome and WasmTestOnFirefox scenarios. Each test assembly runs once per scenario, so this roughly halved the helix work items for that job. Firefox coverage continues on rolling builds via the extra-platforms pipeline.

5. Removed browser_wasm_win from AOT Smoke tests

AOT Smoke tests now only run on browser_wasm (Linux). The Windows AOT Smoke variant is deferred to rolling builds.

Impact by PR type

Library-only PRs (~20% of all builds)

Job	Before	After
Mono WASM (browser_wasm)	Full Chrome+Firefox (~120 work items)	Full Chrome only (~60 work items)
Mono WASM (browser_wasm_win)	Full Chrome (~60 work items)	Smoke Chrome (~4 work items)
AOT Smoke	browser_wasm + browser_wasm_win (2 jobs)	browser_wasm only (1 job)
Android Mono	2 helix jobs	0 jobs
Mono MiniJIT Library Tests	3 platforms (3 helix jobs)	1 platform (1 helix job)
Net savings		~5 fewer helix jobs, ~116 fewer helix work items

EAT tests, CoreCLR WASM tests, and AOT Smoke (Linux) are unchanged — library PRs retain full coverage on those.

CoreCLR-only PRs (~34% of all builds)

No change — CoreCLR PRs were already well-isolated from mono. They trigger 7 WASM jobs (4 build-only + 3 helix), all CoreCLR-flavored.

Mono/WASM PRs (~9% of all builds)

No change — full test coverage preserved on all platforms when mono or WASM code changes.

Rolling/CI builds

No change — all jobs run at full capacity on rolling builds.

[dotnet-policy-service]

Tagging subscribers to this area: @akoeplinger, @matouskozak, @simonrozsival
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR reduces Mono/WASM PR pipeline workload for changes that don’t touch Mono/WASM-specific paths, while preserving full coverage when Mono/WASM code changes and on rolling builds.

Changes:

• Removed the Firefox scenario from the Mono WASM library test job to reduce Helix work items.
• Switched browser_wasm_win Mono WASM library tests to smoke-only on libraries/illink-only PRs via shouldRunSmokeOnly: onLibrariesAndIllinkChanges.
• Narrowed PR triggers for Mono Android jobs and split Mono MiniJIT libraries tests so only linux_arm64 runs on libraries-only PRs.

[radekdoulik]

It looks sensible to me. I think we should add mono smoke firefox on browser_wasm_win to have some minimal coverage.

Besides that, I can look at reducing the current coreclr libraries tests set. It is already clear, that we cannot run all of the coreclr test on CI for performance reasons. We have already disabled some because they would take too long. Last time I triaged them, I chose these which will be under 1 hour on my machine. I can retriage and choose lower threshold.

Would it make sense to have broader coverage of wasm coreclr tests in outerloop or would it cause troubles?

[radekdoulik]

I looked a bit deeper into libraries tests (wasm/coreclr in our case) and it looks like many suites run very quickly, but still have nontrivial start overhead on helix. So more than half of the total time is just the overhead.

It would be interesting to group quick suites together, to reduce that overhead.

From copilot's analysis:

The 172 suites have ~1.5m startup overhead each, so 258m (4.3h) is just overhead and only ~179m (3.0h) is actual test execution.

[davidwrighton]

@radekdoulik Broader coverage in outerloop is great. We can always do that, and the cost turns out to be minimal. Instead of adding a firefox mono smoke run for browser wasm, why don't we make the mono aot wasm run execute on firefox. That should give some coverage on firefox, and work fairly well.