-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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] Move EnableAggressiveTrimming build to runtime
pipeline
#52252
Conversation
.. 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.
Tagging subscribers to 'arch-wasm': @lewing Issue Details.. from
|
This will need a fix for #52194 (comment) which @eerhardt is looking at, to get a green build. |
The work items on this leg have had a > 90% pass rate for at least the last 14 days. |
based on the new lanes failing in #52194 (comment) that is probably trimming related? |
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. |
Tests are built for AOT (in We need to keep this job green, and since it can break with any library change, we want it to be in |
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 |
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. |
|
Great 👍 thanks a lot |
runtime (Build Browser wasm Release AllSubsets_Mono) failure is #51131
|
.. from
runtime-staging
, so any changes that break that can be caught,and fixed. Any test failures in
runtime-staging
don't fail the jobitself, so it gets missed.