build: cross-compile and pack release artifacts concurrently - #599
Conversation
buildServerBinaries compiled the 5 server platforms strictly in sequence and packPublicPackages packed the 19 public packages one by one. Both loops are independent per item, so run them through a new mapWithConcurrency helper (order-preserving results, no new work after a failure, in-flight children awaited): - all 5 go builds run at once - the Go build cache is concurrency-safe, and the win comes from overlapping the serial link phases (~20% faster on a cold cache: 1m56 -> 1m33 locally; proportionally more with a warm cache) - pnpm pack runs with concurrency 8 into the shared tarballs dir (distinct filenames; the cli prepack rebuild keeps its production telemetry-channel stamp) Validated with moon run release:pack plus verify-tarballs (19 installable tarballs) and new unit coverage for the helper.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
There was a problem hiding this comment.
Pull request overview
This PR speeds up release artifact generation by introducing a reusable concurrency-limited async mapper and applying it to parallelize Go cross-compilation and npm package packing in the release scripts.
Changes:
- Added
mapWithConcurrencyhelper to run async work with a concurrency cap while preserving input order and stopping new work after the first failure. - Updated
buildServerBinariesto compile all configured server platforms concurrently. - Updated
packPublicPackagesto pack public packages concurrently (cap 8) into the shared tarballs directory.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| scripts/release-artifacts.mjs | Switched platform builds and public package packing from sequential loops to concurrency-limited mapping. |
| scripts/dev-process.mjs | Added mapWithConcurrency helper implementing order-preserving, fail-fast, concurrency-limited async mapping. |
| apps/cli/tests/unit/scripts/dev-process.test.ts | Added unit tests for mapWithConcurrency (ordering, concurrency cap, fail-fast semantics, empty input). |
A NaN limit produced zero worker lanes via Array.from({length: NaN}),
so the call returned an all-undefined result array without running any
work - a silent no-op. Validate the limit as a positive integer and
early-return on empty input. Addresses the Copilot review finding on
#599.
…extgen into claude/parallel-release-builds
Summary
buildServerBinariescompiled the 5 server platforms strictly in sequence andpackPublicPackagespacked the 19 public packages one by one. Both loops are independent per item, so they now run through a newmapWithConcurrencyhelper inscripts/dev-process.mjs(order-preserving results, no new work started after a failure, in-flight children awaited).go builds run at once — the Go build cache is concurrency-safe; the win comes from overlapping the serial link phases. Measured locally with a cold cache: 1m56 → 1m33 (~20%); warm-cache runs (the CI norm with the restored setup-go cache) save proportionally more.pnpm packruns with concurrency 8 into the shared tarballs dir (distinct filenames; the@zitadel/cliprepack rebuild keeps its production telemetry-channel stamp).Validation
moon run release:packthennode apps/cli-journey-e2e/scripts/verify-tarballs.mjs dist/release/<v>/npm— 19 installable tarballs verifiedbuildServerBinariesinvocation (go clean -cachebefore each): sequential 1m55.9s, parallel 1m32.8svitest run tests/unit/scripts/dev-process.test.ts tests/unit/scripts/release-artifacts.test.ts— 12 tests green (new coverage: order preservation, concurrency cap, fail-fast semantics, empty input)moon run cli:lint— cleanRelease notes / changeset
Notes
go/pnpmchildren cannot be abandoned safely, so a failing platform/package surfaces after the current lane items settle, with the first error rethrown.