Tests: Shard JS unit tests

[sirreal]

What?

• Split out JS date unit tests
• Shard main JS unit tests into 4 shards.

See this comment for findings on different numbers of shards.

Anecdotally, the JavaScript unit tests run in ~2 minutes (parallelized on 4 workers * 2 node versions) instead of ~3:45 currently on trunk.

Follow up to #59904.

Why?

We can speed up the JS unit tests by sharding them — they're split up and different tests are run in parallel on different workers.

[desrosj]

A minute for each test run with shards is great. I'm curious how long the test step would be for 2 shards, though.

[sirreal]

Yep! I'll pause this work for about a week, but before proceeding I plan to do some testing to find a sweet spot by testing different numbers of shards.

[sirreal]

Testing runs:

Shards	Clock time	Accumulated time	Longest shard
1	4:10	7:34	4:00
2	2:37	9:29	2:29
3	2:26	12:11	2:16
4	1:58	13:22	1:50
5	2:02	16:30	1:53
6	1:56	18:00	1:45

This is only 1 run for different shard numbers so is far from perfect but gives us an idea of where the sweet spot is.

Clock time is the time reported for the action. I think it includes time waiting for the workers to be ready.
Accumulated time is what's reported under "usage" - its the sum of the time of all the different shard runs.
Longest shard is the longest time reported for a single shard, this seems relevant because it represents a lower bound, the whole workflow can't complete any faster than its slowest individual run.

4 shards seems like a good number. It's the fastest run overall, and is not a large jump in accumulated time (occupying workers for more time that other workflows could use) from 3.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: sirreal <jonsurrell@git.wordpress.org>
Co-authored-by: desrosj <desrosj@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[desrosj]

Let's give it a shot! I agree that 4 seems to be the current sweet spot. Added a few small change requests to address before merging. But no need to re-review.

[talldan]

Small note, whenever changing job names like this (for what was formerly a required check for merging into trunk), the required status checks may also need to be updated in the repo settings to include the new job names (under the branches tab).

Access to that may vary so it might require asking someone else to do it.

[desrosj]

Sorry about that, @talldan! I forget sometimes that they are associated with the human-readable names assigned. I wish that they were by workflow file instead. Noted for the future though. Thanks!