Filed from the #10227 shard-count work (PR #10376). Not fixed there — out of that card's declared region, and it wants its own measurement.
What was measured
Run 32396909164 raised Test Core from 3 to 6 shards and ran the full 77-package list. The Checkout repository step of the six Test Core shards, all started within 2 seconds of each other on the same run:
| shard | Checkout repository | fixed overhead (Set up job → end of "Compute this shard's package set") |
|---|
| 1/6 | 155s | 194s |
| 2/6 | 14s | 48s |
| 3/6 | 21s | 54s |
| 4/6 | 13s | 50s |
| 5/6 | 13s | 59s |
| 6/6 | 309s | 346s |
Same workflow, same commit, same runner label, same step, a 24x spread. For comparison, the 3-shard baseline run 32392712980 had all three shards at 57s / 65s / 61s of fixed overhead — tight.
Why this matters
The test job checks out with fetch-depth: 0 (full history, needed so turbo --affected can diff against the PR base). Every Test Core shard, every Dogfood shard, Build Core, Build Docs, Console Pin Gate and Temporal Conformance start within seconds of each other and each pulls the full history. Raising the shard count multiplies the number of simultaneous full clones, and the tail of that distribution is where shards 1/6 and 6/6 landed.
The consequence for capacity planning is the part worth recording: per-shard fixed overhead is not a constant you can multiply by the shard count.#10227's analysis (and this issue's parent PR) assumed ~60s per shard from the 3-shard baseline. That holds at the median and is wrong in the tail — 194s and 346s are 3x and 6x the assumed figure, and they come straight off whatever budget the shard has against #4859's 420s line.
Candidate directions (unmeasured — this is a finding, not a plan)
- A partial/filtered clone (
filter: blob:none) instead of full history. turbo --affected needs the merge-base commit reachable, not every blob in history. - A fetch depth bounded by something real (the PR's commit count plus margin) rather than 0, with the existing
git fetch --no-tags fallback in "Compute this shard's package set" covering the miss — that fallback already exists and already falls back to the FULL package list when the merge-base cannot be resolved, so the failure direction is conservative. - Or simply confirming that GitHub-side clone throughput is the binding constraint before changing anything: the two slow legs may be an artifact of this one run rather than a reproducible tail.
⚠ Whoever picks this up should measure across several runs first. One run establishes that the spread exists; it does not establish its shape.
Filed from the #10227 shard-count work (PR #10376). Not fixed there — out of that card's declared region, and it wants its own measurement.
What was measured
Run 32396909164 raised Test Core from 3 to 6 shards and ran the full 77-package list. The
Checkout repositorystep of the six Test Core shards, all started within 2 seconds of each other on the same run:Checkout repositorySame workflow, same commit, same runner label, same step, a 24x spread. For comparison, the 3-shard baseline run 32392712980 had all three shards at 57s / 65s / 61s of fixed overhead — tight.
Why this matters
The
testjob checks out withfetch-depth: 0(full history, needed soturbo --affectedcan diff against the PR base). Every Test Core shard, every Dogfood shard, Build Core, Build Docs, Console Pin Gate and Temporal Conformance start within seconds of each other and each pulls the full history. Raising the shard count multiplies the number of simultaneous full clones, and the tail of that distribution is where shards 1/6 and 6/6 landed.The consequence for capacity planning is the part worth recording: per-shard fixed overhead is not a constant you can multiply by the shard count.#10227's analysis (and this issue's parent PR) assumed ~60s per shard from the 3-shard baseline. That holds at the median and is wrong in the tail — 194s and 346s are 3x and 6x the assumed figure, and they come straight off whatever budget the shard has against #4859's 420s line.
Candidate directions (unmeasured — this is a finding, not a plan)
filter: blob:none) instead of full history.turbo --affectedneeds the merge-base commit reachable, not every blob in history.git fetch --no-tagsfallback in "Compute this shard's package set" covering the miss — that fallback already exists and already falls back to the FULL package list when the merge-base cannot be resolved, so the failure direction is conservative.⚠ Whoever picks this up should measure across several runs first. One run establishes that the spread exists; it does not establish its shape.