* fix(windows-seed): record slow Windows files in full instead of at the 6-minute deadline
The first Windows recording on eca247e99 (run 39008249142) killed
test/gstack-doctor.test.ts at the 360 s per-file deadline and would have
seeded it at 360 s, although it takes about 484 s on Windows. --record-durations
now honors an explicit --wall-timeout as its per-file deadline, and the
windows-record-durations job passes --wall-timeout 1200 (inside its 30-minute
job limit). The shard job's 15-minute timeout and the shard count are unchanged.
The recording job also uploads its full per-file logs, so a file that fails
while recording (browse/test/cookie-import-native-job.test.ts did in that run)
can be diagnosed.
Intentional pin change: test/windows-native-workflows.test.ts now expects
the --wall-timeout 1200 recording command and the log upload step.
Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com>
* test(windows-seed): refresh the Windows free-suite duration seed from a windows-latest recording
Recorded by the windows-record-durations job (run 39009112245, recorder exit 0,
no failed or timed-out files) at 31150049, with the full per-file deadline:
638 -> 738 durations (106 added, 6 removed). test/gstack-doctor.test.ts 392 s
and test/hook-scripts.test.ts 135 s were unseeded;
browse/test/cookie-import-native-job.test.ts 99 s -> 118 s. With the new
seed the six-shard plan isolates gstack-doctor in its own shard (392 s
predicted) and puts the other two in separate shards (265 s each), where the
old seed packed cookie-import-native-job into a 121-file shard.
Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com>
* docs(changelog): Windows seed refresh entry
Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com>
* chore(release): stamp v1.91.121.0
Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com>
---------
Co-authored-by: capy-ai[bot] <230910855+capy-ai[bot]@users.noreply.github.com>
