refactor: avoid Dockerfile duplication

[ndr-brt]

WHAT

Currently we have multiple Dockerfile around the codebase that are pretty much the same, to avoid duplication I put one in the root folder and have the dockerize task to copy it in the project build folder.
That will make also the dependabot configuration slimmer

WHY

cleanup

FURTHER NOTES

• deployment-test was calling dockerize for all the modules in the project, now it has been fixed to launch it only for required modules

Closes # <-- insert Issue number if one exists

[paullatzelsperger]

I have my doubts about the merits of this PR overall because I don't see the advantage of replacing several docker file with a Gradle task. What exactly are we optimizing?

I would also dispute the notion that the Docker files are "duplicated", they simply are a build recipe for similar artefacts, not dissimilar to a build.gradle.kts.

More importantly though, this means, that docker images can only be built through Gradle then, which can be a problem. For example, this will break our Docker release process, because there we don't use the dockerize task, but we use several dedicated GH Actions to set metadata and push the image.
Is it really worth re-engineering the release process, just to reduce a few files?

[ndr-brt]

I have my doubts about the merits of this PR overall because I don't see the advantage of replacing several docker file with a Gradle task. What exactly are we optimizing?

the gradle task is already there, I just centralized the Dockerfile (resulting a single file instead of 7 different ones).
Having a single file will facilitate version update but also make eventual changes easier: changing something in a single point is definitely easier than doing it 6 times.

I would also dispute the notion that the Docker files are "duplicated", they simply are a build recipe for similar artefacts, not dissimilar to a build.gradle.kts.

Our build files are providing different runtime flavours (with different dependencies), but the Dockerfile "logic" is the same over the different files: put the fat jar into it, handle configuration and run the application.

More importantly though, this means, that docker images can only be built through Gradle then, which can be a problem. For example, this will break our Docker release process, because there we don't use the dockerize task, but we use several dedicated GH Actions to set metadata and push the image. Is it really worth re-engineering the release process, just to reduce a few files?

There's no change in the build process: the dockerize task is still used, but instead of taking the file from the src/main/docker folder, it will rely on the copyDockerfile task, that will copy the file in the build folder, from which it will be taken to build/publish the image.

[paullatzelsperger]

There's no change in the build process: the dockerize task is still used, but instead of taking the file from the src/main/docker folder, it will rely on the copyDockerfile task, that will copy the file in the build folder, from which it will be taken to build/publish the image.

The docker release process (to dockerhub) does not use dockerize, that is my point. Checkout publish-new-release.yaml and from there actions/publish-docker-image. Instead, we're using dedicated GH Actions for this, that build, set metadata and publish.

we'd have to also execute ./gradlew copyDockerfile before we run the docker/build-push-action@v3 action and adapt the paths therein.

[ndr-brt]

There's no change in the build process: the dockerize task is still used, but instead of taking the file from the src/main/docker folder, it will rely on the copyDockerfile task, that will copy the file in the build folder, from which it will be taken to build/publish the image.

The docker release process (to dockerhub) does not use dockerize, that is my point. Checkout publish-new-release.yaml and from there actions/publish-docker-image. Instead, we're using dedicated GH Actions for this, that build, set metadata and publish.

we'd have to also execute ./gradlew copyDockerfile before we run the docker/build-push-action@v3 action and adapt the paths therein.

oh, yes, I got it wrong, anyway the copyDockerfile has been put as a dependency of the shadowJar task, so it gets executed before every publish anyway.

I mean, in the publish-docker-image we're using gradle anyway (to build the jar), why don't leverage it and have a unique process to do that?

I also noticed, in publish-docker-image:

• the otel-agent download is extracting the url from the gradle build file (!!!)
• the legal docs are not attached explicitly, anyway, they are in the image because we're putting in the image all the project root (!!!!!) with source code and everything. (it could be because of the context: . in the build-push-action configuration). (will open an issue for this: published docker images contain all the project tree #1436)

I guess that happened because of the duplication, which is always bad and we should avoid it as much as possible

[paullatzelsperger]

minor nit: if the docker file should remain at the repo root I would call it Dockerfile-template or something, just to make it clear and avoid confusion

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud