Loading
Fix Node heap out-of-memory in compile-production-assets
Problem
The compile-production-assets job was failing with a JavaScript heap
out-of-memory error. The webpack bundle had grown past the 8 GB heap limit.
Root cause
lib/tasks/gitlab/assets.rake checked for a specific runner tag
(saas-linux-large-amd64) to decide whether to raise the Node heap from
8 GB to 16 GB. That tag is now stale. The job runs on Kubernetes runners
tagged gitlab-org-docker-linux-large-amd64, so the check never matched
and the heap stayed at 8 GB even though the runners have more memory.
Solution
Replace the hardcoded runner tag check with detection of the container's
actual memory. The fix reads the cgroup memory limit (cgroup v2
/sys/fs/cgroup/memory.max, or cgroup v1
/sys/fs/cgroup/memory/memory.limit_in_bytes), then falls back to
/proc/meminfo MemTotal if needed. Reading the cgroup limit matters
because in a Kubernetes pod /proc/meminfo reports the whole node's RAM,
not the pod's limit, which would oversize the heap. The Node heap is set
to 75% of detected memory, with a minimum of 8 GB. This works on both the
older VM runners and the newer Kubernetes runners without maintaining a
runner tag list, and auto-scales when runners are resized.
The job logs the chosen heap size and detected memory for troubleshooting.
References
Edited by Stan Hu