fix the circle ci build

[Vampire]

• Removing the setup.sh file and step is just a bit beautifying. Usually you can simply set a project property "foo" via environment variable by setting "ORG_GRADLE_PROJECT_foo" to the desired value. But unfortunately many shells including Bash and the CircleCI implementation have problems setting environment variables which contain dots. So I kept your PUBLISH_KEY and PUBLISH_SECRET environment variables, but simply set the correct project properties from the build script, instead of doing file manipulation.

• Regarding the failed builds, well, we were at a boundary of 4 GiB memory usage in multiple processes. There were the gradlew call, the Gradle Daemon that is now activated by default, a Gradle worker process and a Gradle test executor process. Those 4 processes together often touched the 4 GiB boundary which CircleCI enforces and then starts to kill processes. Gradles native monitoring of course cannot work, as there is plenty RAM and CPU available in the system, so it is also given to the JVM and Gradle does not see that it is reaching any boundary.

  To fix the situation I did the following steps:

  • I disabled the Gradle Daemon completely, which is recommended for CI systems anyway. It is ultimately useful for development machines to speed up work, but for the sake of reliable reproducible builds, it should always be off on CI systems. This is also recommended by the documentation.
  • I set the max memory for the gradlew process to 1 GiB
  • I set the max memory of the test executor process to 1 GiB if the build is running on CircleCI

  Before these changes, the build failed in 50% - 90%. With these changes I ran the build 30 times without a single failure.

  I'd really wonder if your change of setting the max memory to 2 GiB in the org.gradle.jvmargs would have had any effect. I don't think so, as this should only affect the Gradle Daemon process, which by default is restricted to 1 GiB, so you just allowed it to consume more memory, while it was not even the culprit. I guess it just accidentally worked and if you would start 30 builds, you would get quite some failing.

• I also removed the --stacktrace option and added the --info option instead --stacktrace is usually too noisy, e. g. you get a full stracktrace for each deprecation warning and also each build failure, even if the message is clear enough I would not enable this by default. But having --info level output in a CI build usually is more appropriate than lifecycle level, at least that is what the past has told me. :-)

[vivin]

Yes --info is better - I threw --stacktrace in there when I was trying to debug the build failure on circle and then forgot to remove it.

Thanks for figuring this out!

[vivin]

Oh and as far as setting the max memory - I did that because the build would also fail intermittently with heap-dumps, but I don't think that was the actual issue as you said.

[Vampire]

Yeah, I would really wonder if 1 GiB is not enough max daemon memory for this build