heroku / heroku/heroku-buildpack-ruby
Set memory default for Node builds
- Dominant language
- Ruby
- Stars
- 785
- Forks
- 1.8k
- Avg merge
- 1d 9h
- Merged PRs (30d)
- 8
Description
In the Node buildpack we set an ENV var that works around Node's default 1.5 GB memory limit and let's it address all 2.5GB of the memory in the build dynos: https://github.com/heroku/heroku-buildpack-nodejs/blob/master/lib/environment.sh#L32
However if a user is using Ruby and webpacker to run their build, this does not persist for the Ruby buildpack execution.
This means that there are occasionally users who hit the limit and their build will fail:
```
remote: <--- Last few GCs --->
remote: [7875:0x34cd670] 486451 ms: Mark-sweep 1331.0 (1440.7) -> 1317.8 (1442.2) MB, 1564.5 / 0.0 ms (average mu = 0.140, current mu = 0.049) allocation failure scavenge might not succeed
remote: [7875:0x34cd670] 488071 ms: Mark-sweep 1332.5 (1442.2) -> 1319.4 (1443.7) MB, 1534.7 / 0.0 ms (average mu = 0.098, current mu = 0.053) allocation failure scavenge might not succeed
remote: <--- JS stacktrace --->
```
Currently the workaround is setting the ENV var manually:
```
$ heroku config:set NODE_OPTIONS="--max_old_space_size=2560" -a $APP_NAME
```
but this is a simple enough thing that I feel it would be valuable to add it to the Ruby buildpack
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reading lib/environment.sh in the Node buildpack, especially the existing memory-related environment setting. Then locate the Ruby buildpack's environment setup and verify a Ruby build using webpacker can access the larger Node heap; done means the setting persists during Ruby buildpack execution without manual configuration.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- node.js, ruby
- Domain
- build-system
- Issue type
- Feature
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100