tools: add a daily wpt.fyi synchronized report upload

[panva]

This PR introduces a daily job for uploading upstream synchronized WPT executed in four versions of Node.js to the wpt.fyi API.

Test run generated reports: https://github.com/nodejs/node-auto-test/suites/10778564147/artifacts/541679841

Example: Deno has their results submitted next to browsers as well

This PR has two commits, the first one that updates the WPTRunner and adds make target to generate the reports which we'll backport to v19.x, v18.x, and maybe v16.x.

The four versions are:

• 3 based on actions/setup-node - current, lts/* (always Active LTS), lts/-1 (most often the Maintenance LTS)
• latest nightly build per https://nodejs.org/download/nightly/index.json

The job is setup to always execute the respective version's WPTRunner and the supported WPT subset but with the latest synchronized WPT fixtures.

The second commit introduces the daily job's workflow yaml file.

I have requested the credentials for accessing the API. This is a draft until we get them and I retest the flow via nodejs/node-auto-test again once we get the credentials and set them as either organization or repository secrets.

• v19.x lands clean
• v18.x I will open backport PR for the WPTRunner and make target
• v16.x I will open backport PR for the WPTRunner and make target

The workflow file gracefully handles cases when the backport was not done yet and the way the Node.js versions are determined requires no upkeep.

Closes #46443

[nodejs-github-bot]

Review requested:

• @nodejs/actions

[panva]

cc @anonrig

[richardlau]

* the node version built from the current `main`

If the job is only running daily, you could save the build cost by using a nightly build from https://nodejs.org/download/nightly/. actions/setup-node can use nightlies: https://github.com/actions/setup-node/blob/main/docs/advanced-usage.md#nightly-versions

[panva]

If the job is only running daily, you could save the build cost by using a nightly build from nodejs.org/download/nightly. actions/setup-node can use nightlies: actions/setup-node@main/docs/advanced-usage.md#nightly-versions

Great suggestion! Is just nightly going to be a valid target though? The examples suggest It needs a major.x-nightly target which would require upkeep.

[panva]

Run actions/setup-node@v3
  with:
    node-version: nightly
Error: Unable to find Node version 'nightly' for platform linux and architecture x64.

[anonrig]

Great work @panva!

[panva]

@richardlau with a little bit of convincing but it's now using nightly instead of building from main.

[panva]

@KhafraDev It would be amazing if we started thinking about executing fetch()-related WPTs in nodejs/node as well so that they would also get submitted. Just something to think about.

[KhafraDev]

I don't think it's a good idea to run fetch WPTs in node - node doesn't implement fetch and the WPT runner isn't powerful enough to run the tests. Would it be possible for undici to run the WPTs, generate a report, and then for node to fetch the report and combine the results with other tests?

[panva]

I don't think it's a good idea to run fetch WPTs in node - node doesn't implement fetch and the WPT runner isn't powerful enough to run the tests. Would it be possible for undici to run the WPTs, generate a report, and then for node to fetch the report and combine the results with other tests?

Let me think more on this.

Could you port your improvements to the runner back to node?

[KhafraDev]

I'm not sure tbh. The biggest difference is that undici's runner needs to create multiple servers (1 for fetch tests and 1 for websocket tests). With that, it also runs in its own process to ensure that if a tests, for example, blocks the thread or mutates a prototype, there won't be any side effects to the server.

There's also some slight differences between the two - undici will respect META attributes (timeout, etc.) while node's seems to only care about scripts to inject. Undici's will open x amount of workers in parallel while node's opens 1 at a time, etc., etc..

But then, a majority of tests use relative path URLs, and undici's fetch can't do anything with these urls by default (since node doesn't have a default origin and file:// urls can't be fetched). Undici exposes setGlobalOrigin to set a... global origin... that's then used as a base to parse relative urls. I'm unsure how node would do this since undici doesn't export it in its fetch bundle.

All of those issues could be fixed, but I don't really see the benefit if I'm being honest.

[panva]

We should then look into undici producing wpt reports that the job here could pull and submit as one run chunked into 2.

[panva]

cc @nodejs/actions this should be ready to land (#46498 (comment))

[nodejs-github-bot]

Landed in eb2a1ab...65854f1