Trial windows-staging queue (m8i.2xlarge) for Windows Dev Build (do not merge)#3294
Draft
Trial windows-staging queue (m8i.2xlarge) for Windows Dev Build (do not merge)#3294
Conversation
iangmaia
changed the title
Contributor
Author
|
@copilot resolve the merge conflicts in this pull request |
Contributor
Resolved the conflict in |
iangmaia
changed the title
Routes the Windows Dev Build group to the `windows-staging` queue so we can benchmark m8i.4xlarge (Intel Xeon 6 / Granite Rapids) against the prod `windows` queue's c5.4xlarge (Skylake-SP, late-2017). Pairs with Automattic/buildkite-ci#844. Draft only — revert this commit before merging. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The two install:bundle scripts (apps/studio + apps/cli) run inside the electron-forge prePackage hook to produce flat, non-workspaces node_modules trees that can be packaged into the Electron app. They inherit the local npm cache (./vendor/npm) that the root npm ci has already populated 3+ minutes earlier, but without --prefer-offline npm still hits the registry to check whether each cached tarball is the latest matching version. In CI, the lockfile-driven root install just resolved against the registry — the bundle installs (which use --no-package-lock by design, since workspace lockfiles aren't usable in a flat install) are fine to prefer the just-populated tarball cache without re-checking. Local devs running install:bundle outside CI are similarly fine: --prefer-offline falls back to the network when a version isn't cached. Expected savings on the Windows Dev Build prePackage phase: 30-60s. Currently being benchmarked on the windows-staging queue (m8i.2xlarge) via this PR — will compare against build #15296 baseline (no --prefer-offline, x64 23m 54s, arm64 23m 41s). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Empirical comparison (#15378 vs #15296) showed no meaningful win. Subtle reason: with --no-package-lock npm still does full registry resolution to figure out which versions match the semver ranges, and --prefer-offline only changes tarball-fetch behavior, not resolution. The resolver step is most of the bundle-install wall-clock, so the flag isn't doing useful work here. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
iangmaia
force-pushed
the
trial-windows-staging-m8i
branch
from
7d000c6 to
b5acef0
Compare
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
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.
Summary
Routes the Windows Dev Build group (
.buildkite/pipeline.yml) to thewindows-stagingqueue. Pairs with Automattic/buildkite-ci#844, which has the staging queue settled onm8i.2xlarge.Use this branch as the guinea pig for any subsequent staging-queue benchmarks (next likely candidates: caching the bundle
node_modulesdirs, replacing Squirrel.Windows with electron-builder's NSIS).Findings so far
vs. the prod
windowsqueue's c5.4xlarge baseline:Log breakdown of the dev build (#15337 phase analysis):
prePackagehook: 3 m 25 s — two flatnpm installruns (apps/studio+apps/cli).npm install: 2 m 43 s — already optimized via toolkit-style npm cache.Things tried and discarded
--prefer-offlineon the twoinstall:bundlescripts (#15378). No meaningful change vs. baseline (reverted in 7d000c6). Reason: with--no-package-locknpm still does a full registry resolution, and--prefer-offlineonly affects tarball fetching, not resolution.Workflow
This PR remains a draft and must not merge. When future studio-side optimizations are ready to benchmark, push them onto this branch, run a Windows Dev Build via "🚦 Build for Windows?", and compare against the m8i.2xlarge baselines above.
🤖 Generated with Claude Code