Add core WebAssembly tests to WPT #49277
Conversation
| rm -rf main/wasm/core | ||
| cp -r wasm-spec/out/ main/wasm/core/ | ||
| find main/wasm/core/ -type f -name '*.html' -exec sed -i 's/\.\/js\/harness\/testharness/\/resources\/testharness/' {} \; | ||
| - name: Commit changes |
There was a problem hiding this comment.
If you use the peter-evans/create-pull-request action as the WebIDL workflow does, you don't need to manually commit the changes or do anything with git itself.
There was a problem hiding this comment.
Another example is what we do in emscripten to create a PR, request a review from a github team, and set the PR to auto-merge (after approval and passing tests)
There was a problem hiding this comment.
We do something similar in the wpt-metadata repo, but I'm always wary of using 3rd-party libraries for security reasons. However, I see the author of this action is now working for GitHub, so maybe this is less of a concern.
There was a problem hiding this comment.
Yeah, that makes sense. I'm fine either way, up to you.
The Interop 2024 WebAssembly Testing Investigation intends to get WebAssembly core tests running on WPT.fyi (alongside the existing JS API and Web API tests).
This PR adds a GitHub Actions workflow that pulls the latest tests from the WebAssembly/spec repo on a regular schedule (or when run manually) and creates a PR with any new changes.
This mimics the existing process for updating WebIDL tests, which is low risk and low friction. Creating a PR that needs to be reviewed removes the risk of the workflow messing up the wpt repo at the cost of needing manual review of the changes (which is mostly rubber-stamping as in the WebIDL case). I also considered a push model from the spec repo, which could reduce CPU costs and achieve lower latency to propagate changes, but with a substantially more complex solution.
My WPT repo fork has some successful runs that you can look at:
This should match the MVP that the investigation is pursuing and could subsequently be expanded to cover tentative tests from WebAssembly/testsuite or elsewhere. This should let the investigation get to a 67% score in the Interop dashboard.
/CC @jgraham, @gsnedders