JavaScript heap out of memory when using `include` with local or remote templates

[muuvmuuv]

My configuration somewhat fails when using include with local templates.

Minimal .gitlab-ci.yml illustrating the issue

stages:
  - build

include:
  - local: templates/common.yml

build:
  stage: build
  extends: .workspace
  variables:
    GIT_DEPTH: 0
  script:
    - echo 'Build'

templates/common.yml:

.workspace:
  image: debian:12
  before_script:
    - apt-get update -y && apt-get install -yqq git gzip zip xz-utils curl
    - curl -fsSL https://moonrepo.dev/install/proto.sh | PROTO_HOME=$CI_PROJECT_DIR/.cache/proto bash -s -- latest --shell=bash --yes
    - source ~/.bashrc
    - proto install
    - pnpm config set store-dir .cache/pnpm
    - pnpm install

Expected behavior
Paste a public job url.

Host information
macOS 15.5 (24F74)
gitlab-ci-local 4.60.1

Containerd binary
Docker Desktop

Additional context
Add any other context about the problem here.

[thomcom]

Seeing this as well, out of the blue, worked a few weeks ago. It doesn't appear to matter what's in the include:, it's presence causes it to fail.

I'm on Ubuntu 24.04, gcl 4.60.1, node 22.9.0. Downgraded to node 20.6.1, 16.20.2, same effect.

[superewald]

Ran into the same issue (Ubuntu 24.10, gcl 4.61.0, node v22.13.1). I decided to clone the main branch and use the node debugger (node --inspect-brk --loader ts-node/esm src/index.ts) to trace this.

trace

1. gitlab-ci-local/src/parser-includes.ts

   Lines 364 to 365 in bf655d1

   	export function resolveIncludeLocal (pattern: string, cwd: string) {
   	const repoFiles = ParserIncludes.memoLocalRepoFiles(cwd);

   • cwd: /project
   • pattern: test.yml

2. gitlab-ci-local/src/parser-includes.ts

   Line 334 in bf655d1

   result = globby.sync(path, {dot: true, gitignore: true});

   • path: /project

cause

It's important to mention that my my project folder contains a subfolder which heavily uses nested symlinks which in turn contain symlinks and so on. Since globby will expand /project to /project/**/* this is very likely the cause of the OOM crash as it scans thousands of self-referencing folders/files.

reproduce

To reproduce this issue, simply add a symlink into your project folder like ln -s / oom.