ci: install the packed tarball to the fast volume on windows - #137
Merged
Conversation
The windows job intermittently hit timeout-minutes: 20 inside "Verify global install from pack", before running a single test. When that happened on a master push, CI-build.yml - gated on workflow_run.conclusion == 'success' - was skipped, so no release was published. It silently blocked the pkc-js 0.0.85 release. The step has been chronically slow, not newly slow: 8-13m across the last 40 runs going back to June, against a 20m cap, with the whole test suite taking 2.5m. It had already timed out on 2026-07-30 and 2026-08-13. Cause is the destination volume. Windows defaults the npm global prefix to C:\npm\prefix on the OS disk, while npm ci writes a larger tree to the workspace on D:. Measured on windows-latest with an identical warm cache, varying only the destination: C:\npm\prefix 9.1m D:\npm-global 1.4m D:, non-global 1.0m Everything else was ruled out first: dependency resolution is 12s, --ignore-scripts is no faster, npm 12.0.2 is no faster, and --offline succeeds in ~10m - so none of the cost was registry traffic. Note ff6aa9b's --prefer-offline did not fix this. Median step time was ~10.0m before it and ~10.7m after; it was credited with a 17.1m outlier in an already noisy distribution. The flag is kept, since reusing the cache is still correct, but its comment no longer claims to be the fix. Also add .github/** to the pull_request paths. Without it a PR that only touches a workflow does not run CI, so this change could not be tested by its own PR.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe CI workflow now includes ChangesCI workflow
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to This change relocates the Windows global install to the fast volume while preserving command resolution. No actionable merge-blocking risk remains; a minor shell portability cleanup can be handled as follow-up. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
4 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #136
Problem
The windows job intermittently hit
timeout-minutes: 20inside Verify global install from pack, before running a single test. When that happened on amasterpush,CI-build.yml— gated onif: github.event.workflow_run.conclusion == 'success'— was skipped, so no release was published. It silently blocked the pkc-js 0.0.85 release yesterday.The step has been chronically slow, not newly slow. Across the last 40 CI runs:
npm ci, same job, same runnerPrior timeouts: 2026-07-30 (
0382b13), 2026-08-13 (53b42e5), 2026-08-21 (0f6ef94).Cause
The destination volume. Windows defaults the npm global prefix to
C:\npm\prefixon the OS disk;npm ciwrites to the workspace onD:, the runner's fast volume.Measured on
windows-latest, identical warm cache,max-parallel: 1, varying only the destination:C:\npm\prefix(current default)D:\npm-globalD:, plain non-global installEverything else was ruled out first, each with a measurement rather than a guess:
--ignore-scriptsis no faster (8.3m).--offlinesucceeds, exit 0, in ~10m. With no registry access at all the step is just as slow, so none of the cost is registry traffic.The fix
setup-nodeexportsnpm_config_prefix, which takes precedence overnpm config set prefix— an earlier attempt to move the prefix silently did nothing and had to be redone against the env var. So the env var itself is overridden, andD:\npm-globalis added toPATHsobitsocial --versionstill resolves.Two notes on the existing workflow
--prefer-offlinenever fixed this.ff6aa9badded it right after the 2026-07-30 timeout and its comment credits it with fixing a 17m step. Median step time was ~10.0m before and ~10.7m after — it was credited with a 17.1m outlier in an already-noisy distribution. The flag is kept (reusing the cache is still correct) but its comment no longer claims to be the fix..github/**added topull_requestpaths. Without it, a PR touching only a workflow does not run CI — meaning this very change could not have been tested by its own PR.Verification
The windows job on this PR is the test: the step should drop from ~9m to ~1.5m, and
bitsocial --versionmust still resolve from the relocated prefix.Raising
timeout-minuteswas deliberately not the fix — a step taking 9 minutes to install a treenpm ciinstalls in 55 seconds is the actual defect. With this change the windows job should land around 6-7m, restoring real headroom.Summary by CodeRabbit