From 243e4015cbf453448e42f66fbdf99df34adfb331 Mon Sep 17 00:00:00 2001 From: morluto <76467478+morluto@users.noreply.github.com> Date: Sat, 14 Nov 2026 11:47:46 +0800 Subject: [PATCH] docs(ci): remove dated shard measurements from the testing guides (#10414) * docs(ci): move dated shard measurements into a verification record The testing guide and testing-lanes guide mixed the October 2026 shard budget and stale-history measurements into current rules. Move them to docs/verification/ci-shard-scheduling-2026-10-20.md and link it from the rules they justify. * docs(ci): drop dated shard measurements instead of keeping a record --- docs/development/testing.md | 29 ++++------------------------- docs/testing-lanes.md | 10 ++-------- 2 files changed, 6 insertions(+), 33 deletions(-) diff --git a/docs/development/testing.md b/docs/development/testing.md index 506b974ceb..fac0ef580d 100644 --- a/docs/development/testing.md +++ b/docs/development/testing.md @@ -1091,32 +1091,11 @@ existing four-minute timing collection plus the bounded diagnostic stages. Fast built shards target under ten minutes of uncontended shard-job execution. That figure is the `test-shard` job. The job waits for classification and the -build, and the portable-test merge runs after the slowest shard. On 2026-10-20, -run `39451548945` measured those surrounding jobs with runner queue excluded: -classification 15 seconds, build 49 seconds, and the portable-test merge 29 -seconds. Shard 1/5 of that run spent 22 seconds before built Vitest and 3 -seconds after it, including `npm ci` at 9 seconds. `node_modules` is about 674 -MiB, so publishing it as a shared artifact would transfer more data than that -install saves. The npm download cache stays the setup cache. - -File timings from that run put the built suite at 7944 seconds of module time. -The sequencer keeps each file's full duration on one worker. Extra workers -overlap other files in the same sequence group, and `process-boundary` runs -after that group. Scheduling the unsplit inventory onto five shards peaks at -820 seconds of tests. That run's slowest built shard job lasted 925 seconds -(shard 4/5), and shard 1/5 spent 874 seconds in built Vitest, so hosted job -time sits above the file schedule. Six shards of the same inventory peak at -684 seconds of tests. Eight shards, after the 578-second loader file is split -by case count (54 cases stay in that file and 46 move into each of three -files), peak at 513 seconds of tests. With the measured 25-second shard setup, -that shard job is about 538 seconds. Adding the measured classification, build, -and merge makes an uncontended portable critical path of about 631 seconds, -still before the gap between this file schedule and hosted Vitest. Runner queue -is separate and grows when more shard jobs compete for runners. +build, and the portable-test merge runs after the slowest shard. Runner queue is +separate and grows when more shard jobs compete for runners. The npm download +cache stays the setup cache rather than a shared `node_modules` artifact. `process-boundary` stays serial because process-tree sampling shares the host. -Raising the worker cap from two to four on this four-core host cut a six-file -acceptance sample from 96–101 seconds to 71 seconds and did not remove the -single-file floor. Hosted CI jobs use four workers; other hosts stay at two +Hosted CI jobs use four workers; other hosts stay at two because they are shared with other checks. Full qualification keeps six covered shards; its longer instrumentation is outside this fast budget. diff --git a/docs/testing-lanes.md b/docs/testing-lanes.md index 459b10a2fc..7be47fb08c 100644 --- a/docs/testing-lanes.md +++ b/docs/testing-lanes.md @@ -842,14 +842,8 @@ branches are not producers. A tier with no qualifying artifact leaves history unset, and Vitest uses its own assignment. A later schedule that reuses qualification without uploading timings leaves the previous artifact in place. -On 2026-10-21 the newest full history was run -`39545047294`, recorded before compiled-CLI session reuse. Fast run -`39552964873` packed its eight built shards from that history, and those shard -jobs executed for 319–591 seconds. Replaying that run's file durations through -the sequencer's two-worker schedule balances every shard at about 404 seconds -of file time. The same replay with the stale history weights leaves the slowest -shard near 547 seconds and the fastest near 293. That spread is file-schedule -time, not runner queue, which is why each tier keeps its own history. +Each tier keeps its own history because stale weights from another tier, or +from before a large test change, unbalance the shards. CI assigns discovered files by historical duration rather than dividing only by file count. A file with no recorded duration, such as a newly added or renamed test, is weighted at the median recorded duration until a published