mirror of
https://github.com/pnpm/pnpm.git
synced 2026-07-14 01:32:40 -04:00
81cbd50a89
* ci: run TS and Rust test jobs on Blacksmith runners Move the unit and e2e test jobs that were still on GitHub-hosted runners onto Blacksmith 8vcpu runners, matching the Blacksmith runners the lint/detect/ancillary jobs already use. - TS CI (ci.yml): test-smoke and the test/test-windows matrices now pass blacksmith-8vcpu-ubuntu-2404 / blacksmith-8vcpu-windows-2022 into the reusable test.yml. - Rust CI (pacquet-ci.yml): the test matrix ubuntu/windows legs move to the same Blacksmith labels. The macOS leg stays on macos-latest because Blacksmith offers no macOS runners. The Bencher upload workflow validates testbed names against strict ubuntu/windows/macos regexes, and both test workflows derived that slug by stripping "-latest" from the runner label, which no longer works for Blacksmith labels. test.yml now maps *ubuntu*/*windows* labels to the bare slug, and the Rust test job derives the slug (and its artifact name) from matrix.os_label instead. * test(cli): make stale-pin-dedupe robust on coarse-mtime filesystems The three stale_pin_dedupe tests each run two back-to-back installs, rewriting package.json between them, and assert the second install re-resolves the bumped version. pnpm and pacquet both gate their incremental-install fast path on a manifest's mtime being newer than the previous install (optimistic_repeat_install). The two installs run a few hundred milliseconds apart, so on a filesystem whose mtime granularity is coarser than that gap the rewritten manifest lands in the same mtime tick as the first install, the edit is not seen as newer, re-resolution is skipped, and the lockfile keeps the stale version. This surfaced on CI runners whose filesystem has second-granularity mtimes: the tests pass on ext4-backed runners and local dev but fail deterministically there. It is not a pacquet-vs-pnpm divergence — the mtime fast path behaves the same in both stacks, and forcing the second manifest's mtime equal to the lockfile's reproduces the failure locally regardless of which baseline (wall clock or lockfile mtime) the gate uses. Model the intended scenario explicitly: push the rewritten manifest's mtime well past the lockfile's so the second install reads it as a genuine later edit, matching what a user editing the manifest at a later time would produce. The assertions still exercise the real stale-pin-refresh behavior. * ci: use Blacksmith windows-2025 label for the test jobs Blacksmith's Windows runners run Windows Server 2025; the valid labels are blacksmith-<N>vcpu-windows-2025. The windows-2022 label matches no runner, so the Windows test legs would queue forever. Point them at the windows-2025 label instead. * ci: run the Build pnpr jobs on Blacksmith The two build-pnpr legs compile the pnpr binaries the TS test jobs consume; they gate those tests but were still on GitHub-hosted runners. Move them onto the same Blacksmith 8vcpu labels as the test jobs (ubuntu-2404 / windows-2025). build-pnpr.yml keys its disk-cleanup gate, cache, and artifact name off `runner.os`, which is unaffected by the label change.