CI: trim fixed overhead from the sandbox create flow#35355
CI: trim fixed overhead from the sandbox create flow#35355valentinpalkovic wants to merge 2 commits into
Conversation
|
|
View your CI Pipeline Execution ↗ for commit a080575
💡 Verify your cache is correct by running tasks in a sandbox. Read docs ↗ ☁️ Nx Cloud last updated this comment at |
Package BenchmarksCommit: The following packages have significant changes to their size or dependencies:
|
| Before | After | Difference | |
|---|---|---|---|
| Dependency count | 34 | 34 | 0 |
| Self size | 22.41 MB | 2.40 MB | 🎉 -20.02 MB 🎉 |
| Dependency size | 22.54 MB | 42.56 MB | 🚨 +20.02 MB 🚨 |
| Bundle Size Analyzer | Link | Link |
158e3c6 to
7631bf7
Compare
Four independent trims, measured on a timestamped local reproduction of angular-vite sandbox creation (107s -> 56s) and a phase decomposition of the CI create jobs (83-106s 'Create Sandbox' step): - Yarn setup becomes two file writes. installYarn2 ran 'yarn set version berry' plus chained 'yarn config set' calls: ~12 yarn boots and two network downloads (corepack's bootstrap yarn, then the latest Berry) per sandbox. The sandbox now vendors the repository's own pinned yarn release via yarnPath and writes .yarnrc.yml directly. packageManager is pinned in the sandbox package.json to the same version: without the field, corepack auto-pins its classic bootstrap yarn, and JsPackageManagerFactory would read that field and misclassify the sandbox as Yarn 1 (caught by the local reproduction; installs kept working through yarnPath delegation while the CLI ran classic-syntax commands). - The final 'yarn install' no longer wipes node_modules first. The wipe forced a full re-extraction of the tree (~10-25s on CI) that yarn's incremental install makes redundant. - Extra sandbox deps carry explicit version ranges, so addExtraDependencies does not probe the registry (a subprocess each) to resolve 'latest' for packages whose major we already know - and sandbox contents stop drifting when a new major is published. - The executor images move to cimg/node:22.22.3, matching .nvmrc. That satisfies Angular's minimum Node version, so the per-job 'node/install' step (~9s on every angular create/dev job) is gone; the create jobs also pre-warm the npx cache for the pinned gitpick version the CLI spawns, so the template download does not pay a cold npx install. Rejected while implementing: passing skip-install to the init CLI step (would fold init's install into the final one, ~15-25s) silently no-ops all addon configuration, because postinstallAddon resolves each addon's postinstall hook from the sandbox's node_modules and returns quietly when resolution fails - addon-vitest's setup would disappear from sandboxes.
7631bf7 to
a080575
Compare
The readiness probe fetched /iframe.html and re-ran the dev task on any failure. But the fetch can fail while a dev server owns the port - a cold compile outlasting the timeout, or the server resetting connections before its middleware is up (seen on a sveltekit shard: the probe got a reset, the task spawned a second server, and that server crashed the job with EADDRINUSE once its own compile finished). A held port now counts as ready via a TCP-connect fallback; every consumer of the dev task performs its own HTTP wait before using the server, so this cannot mask a dead server. This also replaces the earlier CI-only 180s probe timeout with behavior that is correct locally too.
|
Measured on this PR's pipeline (workflow
The CI delta is smaller than the local −48%: warm image-level caches on CI already absorbed part of what the local reproduction paid (corepack/npx cold installs). The structural win is the angular chain head (the workflow's critical path) plus ~10-25s on every one of the 15 create jobs. Status note: the branch HEAD adds one more commit ( |
|
HEAD validated via the stacked child run: 82/82 green on workflow 069b53d0 — the Step timings from that run (final commits):
The Note: this PR's own branch checks still point at the earlier canceled pipeline — a |
Follow-up to #35353; the angular-create investigation (12 verified findings from the create-job phase decomposition + a timestamped local reproduction).
What (four independent trims, scripts/CI only)
installYarn2ranyarn set version berry+ chainedyarn config setcalls: ~12 yarn boots and two network downloads (corepack bootstrap yarn, then latest Berry) per sandbox. The sandbox now vendors the repo's own pinned yarn release viayarnPathand writes.yarnrc.ymldirectly.packageManageris pinned to the same version - without the field, corepack auto-pins its classic bootstrap yarn andJsPackageManagerFactorymisclassifies the sandbox as Yarn 1 (caught by the local E2E reproduction: installs kept working through yarnPath delegation while the CLI ran classic-syntax commands). Side effect: sandboxes now run the exact yarn version the monorepo pins instead of floating on latest Berry.rm -rf node_modulesbefore the final install - the wipe forced a full re-extraction (~10-25s on CI) that yarn's incremental install makes redundant.addExtraDependenciesstops probing the registry per package and sandbox contents stop drifting on new majors.cimg/node:22.22.3(matching.nvmrc), which satisfies Angular's minimum - the ~9snode/installstep disappears from every angular create/dev job. Create jobs also pre-warm the npx cache for the pinned gitpick version, so the template download skips its cold npx install.Rejected while implementing
skip-installon the init CLI step (would fold init's install into the final one, ~15-25s):postinstallAddonresolves each addon's postinstall hook from the sandbox's node_modules and silently returns when resolution fails - with the install skipped, all addon configuration (including addon-vitest's setup) would silently disappear from sandboxes.Measured (local timestamped E2E, angular-vite full creation)
yarn task sandbox(link mode)packageManagerpin only; deps + .storybook byte-identicalVerified:
.yarnrc.ymlwriter probed directly against both logFilter variants;yarn nx run-many -t checkclean; normal + daily configs generate correctly (nonode/installsteps remain).CI create-job step timings will be posted from this PR's pipeline.