Skip to content

Dependency Scan fails for large scala project (signal: killed, lack of memory)

Summary

I was back and forth on whether to file this as a bug or feature request, but settled on bug because the customer can't run dependency scans unless they fork our analyzer to add changes to the way it calls sbt.

If you have a very large project (the reporting customer's is a scala project with over 10k files) the dependency scan hangs and then fails with a signal: killed message. There's no error from the scan itself but we saw the runner pod getting evicted, near as we could tell due to a lack of memory.

The same runner could build the project, but only after they added additional options to sbt. So we think the runner itself is big enough but since there's no way to configure sbt or JAVA_OPTS for dependency scans they ended up being left with forking our copy and changing it in the code.

Steps to reproduce

  • Run dependency scans on a very large project

Example Project

Customer's project is on their self managed instance, I didn't have a sufficiently large scala project to test with.

What is the current bug behavior?

  • Dependency scan runs out of memory, no way to configure it

What is the expected correct behavior?

  • Customer would like a way to configure JAVA_OPTS to fine tune the way java and sbt are used in the scan

Relevant logs and/or screenshots

This is where it's getting killed in the job log:

[info] compiling 8 Scala sources to /builds/analytics/analytics/project/target/scala-2.12/sbt-1.0/classes ...
[info] Non-compiled module 'compiler-bridge_2.12' for Scala 2.12.16. Compiling...

signal: killed
+ runner_script_trap
+ exit_code=1

Output of checks

GitLab environment info

GitLab / Runner version 15.11

Here's the analyzer and java and related java tools versions from the job log:

gradle          7.3.3 6.7.1     /gemnasium-maven/.tool-versions
java            adoptopenjdk-17.0.2+8 ASDF_JAVA_VERSION environment variable
maven           3.6.3           /gemnasium-maven/.tool-versions
sbt             1.6.1           /gemnasium-maven/.tool-versions
openjdk version "17.0.2" 2022-01-18
OpenJDK Runtime Environment Temurin-17.0.2+8 (build 17.0.2+8)
OpenJDK 64-Bit Server VM Temurin-17.0.2+8 (build 17.0.2+8, mixed mode, sharing)
[INFO] [gemnasium-maven] [2024-06-27T20:41:37Z] [/go/src/app/cmd/gemnasium-maven/main.go:55] ▶ GitLab gemnasium-maven analyzer v3.15.3

Possible fixes

We saw a similar issue for spotbugs that had a workaround of setting the java opts, and we eventually increased the default memory as well. But we couldn't find a related way to override java opts for dependency scans. Can we?