build(mac): drop webpack heap from 6 GB to 4 GB on the macOS build#9968
Merged
Conversation
The 6 GB ceiling set by #9967 was too aggressive for the macOS x64 VM's total RAM. Build #1295 on `pgabf-macos-x64` failed in `_build_runtime` at `unzip electron-vX.X.X-darwin-x64.zip` with exit code 2 — never even reached webpack. That points at OS-level memory pressure spilling out of the Node process and starving the rest of the build: at 6 GB reserved, the box runs out of RAM long before Terser actually needs the full ceiling. Drop back to 4 GB, which still gives Terser a full extra gigabyte beyond the original 3 GB setting that OOM-killed webpack in #1294, but leaves enough headroom for the other steps in the appbundle build to coexist. Only the macOS appbundle path changes (see pkg/mac/build-functions.sh); linux/pip/Makefile and dev-machine builds keep the 3 GB the `bundle` npm script ships with.
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughThe PR reduces the Node.js V8 old-space heap limit in the macOS build process from 6 GB to 4 GB by changing ChangesNode.js memory limit adjustment
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes Possibly related PRs
✨ Finishing Touches📝 Generate docstrings
🧪 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 |
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
pgabf-macos-x64failed in_build_runtimeatunzip electron-vX.X.X-darwin-x64.zipwith exit code 2 — never even reached webpack — which points at OS-level memory pressure spilling out of the Node process and starving the rest of the build.pkg/mac/build-functions.sh); linux/pip/Makefile and dev-machine builds keep the 3 GB thebundlenpm script ships with.Caveat
--max-old-space-sizeis a ceiling, not a reservation, so 6 GB shouldn't strictly have caused the unzip failure unless something else (worker leftover, disk pressure, or a transient flake) was contributing. 4 GB is the safe step back; if the next build still fails at unzip we should look at the worker's free RAM/disk rather than tune the heap further.Test plan
pgadmin4-macos-qaon bothmacos-x64andmacos-arm64and confirm the appbundle builds successfully end-to-end._build_runtime(electron unzip) without exit code 2.92% [0] sealing asset processing TerserPlugintoemitting/done.Summary by CodeRabbit