Open remcomokveld opened 4 days ago
Hi @remcomokveld, thank you for reporting this!
Could you please share the output of the action and the output of the step that runs your tests? If possible, both with the 2.0.0 and with the 2.0.1 of the action.
This is a proprietary project so unfortunately I can't just share logs, but I can look for stuff in the logs. Anything specific you'd like me to look out for?
Would it be possible for you to create a support issue with Datadog and share the logs there?
If not, it'd be helpful to see the contents of GRADLE_OPTS
and JAVA_TOOL_OPTIONS
environment variables before the Datadog config action and before the action that runs your tests. Also, if possible, the contents of the gradle.properties
file of your project, in particular org.gradle.jvmargs
, if specified.
Last friday our CI suddenly started failing with
Java heap space
and it took a couple of days to figure out what was the cause.After a lot of investigation it turns out that, because we were using the action as
datadog/test-visibility-github-action@v2
our CI instances started pulling in 2.0.1 when it was released and apparently that adds so much memory overhead to the gradle daemon process that it suddenly didn't have enough RAM to execute the build.Maybe this is expected because the javaagent is now added to more processes but I would not expect a monitoring tool to add that much overhead that a process which usually runs at ~9GB of RAM would start throwing OOM errors.
It's a bit of a mystery overall and hard to reproduce, but reverting back to 2.0.0 completely fixed the issue for us so it may be worth an further investigation.
Please let me know if I can help you in any way with the investigation