Quoted org.gradle.jvmargs argument is incorrectly handled, resulting in Daemon startup failure
#234
Comments
ribafish
changed the title
org.gradle.jvmargs / java heap sizeorg.gradle.jvmargs / java heap size
|
Thanks for the report. Is the project public so I can inspect the output/logs directly? The only thing I can think would be different is that the This provides all of the caching/integration benefits of the |
|
I can reproduce this issue: it appears that the entire content of Note that if the order of jvm args is reversed, the failure is "Invalid initial heap" instead of "Invalid maximum heap". Unfortunately I don't currently have an idea on how to fix this, but I think that separating the "Setup Gradle" from "Execute Gradle" steps is a valid workaround. |
bigdaz
changed the title
org.gradle.jvmargs / java heap sizeorg.gradle.jvmargs argument is incorrectly handled, resulting in Daemon startup failure
|
Hi Daz, thank you for the speedy reply. Separating the gradle setup from the build invocation does indeed fix the issue. 👍 Just out of curiosity, why do you disable the daemon, since it is stated in gradle docs that leaving the daemon enabled is recommended for both user and CI machines? |
This was done to avoid locks being held by the daemon, which prevent the Gradle User Home from being cached. But this was meant to be a temporary solution, pending a proper fix: see #113 |
|
In issue #113 you wrote that if we were to use Also, another thing I noticed is that subsequent builds aren't fully using/reusing the configuration cache, even on the same commit, but I can see it should be restored and saved empty in post, which I understand as no changes. Are you by any chance disabling that somewhere as well? Restore: Save (post): Build scan/Performance/Configuration:
Locally, |
No, it wouldn't be any different. But the failure would show up when trying to save the Gradle User Home, and thus would be attributed to the One option would be for a user to explicitly opt-in to the daemon via this action. But since there's a clear path to handling this automatically (track all started Gradle daemons and stop them before saving Gradle Home), I'd rather invest the effort in that. This will work whether you run the build with
No, the action doesn't do anything to disable configuration caching. It should work. |
Yes, I see this line, but when running with Full log until that line: |
|
@ribafish To determine the property at fault, your best bet would be to add a call to the This looks to be a workflow configuration issue, and not a problem with save/restore of Gradle User Home. I'm going to close this issue but please open a new issue:
|
|
Oops. Of course this issue needs to stay open, since it's a legitimate problem when using |
|
I'm going to close this issue. There is a simple workaround: use a separate |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Our build is failing when specyfiying
org.gradle.jvmargs/ java heap size:with output:
But it works when we set it to the
gradlewwrapper when running it manually:This is using the
ubuntu-latestrunner, which we know has 7gb of RAM, but we tested it extensively with the specified settings and never had OOM problems with them. It's a large project, so maximizing the available heap is very important for build preformance (on a local machine with 12g heap size it uses roughly 9g).Without these jvm settings (just deleted the
-Dorg.gradle.jvmargsline), we're getting failed build in the configuration stage already:The text was updated successfully, but these errors were encountered: