UseCGroupMemoryLimitForHeap replaced UseContainerSupport

[patsevanton]

https://discuss.circleci.com/t/unrecognized-vm-option-usecgroupmemorylimitforheap/37088/2
https://support.circleci.com/hc/en-us/articles/360048152911
jasongilman/proto-repl#282
jenkinsci/kubernetes-operator#554

[arey]

Thank you @patsevanton. @odedia are you ok for this PR?
Not sure that the UnlockExperimentalVMOptions option is still necessary.

[patsevanton]

Change -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap to -XX:MinRAMPercentage=50.0 -XX:MaxRAMPercentage=80.0

jenkinsci/kubernetes-operator@59d522c

[odedia]

Is this change only for docker-compose? I would expect similar change to be necessary for Kubernetes deployments. On the other hand, if you're building the images using mvn spring-boot:build-image that it should already be optimized for containerised workloads.

[patsevanton]

Now only for docker-compose. I can add java option for Kubernetes. But you don`t use them.

[patsevanton]

https://bugs.openjdk.java.net/browse/JDK-8194086 - Remove deprecated experimental flag UseCGroupMemoryLimitForHeap

[arey]

In this repository, we provide a Dockerfile that is using for base image the latest image for Java 11: adoptopenjdk:11-jre-hotspot. The UseCGroupMemoryLimitForHeap option should be removed.

The README.md references the usage of Buildpacks through the mvn spring-boot:build-image command line (configured in the pom.xml to with the name odedia/${project.artifactId}). I suppose the base image is a Java 11. As @odedia said, the generated image should be optimized for Docker. No need of this old option.

So we propose 2 ways to build Docker image. And I suggest to accept this PR.

[patsevanton]

Added Relocate skaffold.yaml to root directory.
Merge this PR or create another pull request for Relocate skaffold.yaml to root directory?

[patsevanton]

Hello.
Added Relocate skaffold.yaml to root directory.
Merge this PR or create another pull request for Relocate skaffold.yaml to root directory?