galexrt
commented
4 years ago From my perspective it simply depends.
Building the binaries and then copying them into a Docker container can have the advantages of "easily" being to able to separately publish the binaries, e.g., Golang projects on GitHub most of the time release binaries and Docker images.
You could copy the binaries out of the container after docker build to have binaries as well, but there isn't really too much "difference" if you think about then. Same result, Docker image and binaries.
Regarding "Docker-in-Docker", as there are more and more ways to build containers without Docker (e.g., buildah, etc) and even without root and / or privileged: true makes it more viable to build images in the CI without "second thoughts" again.
I have a ticket open #2 which is generally aimed at "redoing" the whole project here to be "more uptodate and use the new funky cloud native tools". I just haven't come around to that yet, but I have it on my roadmap.
Let me know if that answers your questions / points. Thanks!
BartoGabriel
In the project, the construction part is done directly from the gitlab-cy file with the goland image. But another way to do it is to handle this build in a dockerfile (eg a multistage).
I like the idea that everything is in a Docker and being able to build in any environment with the same version of goland. At the same time, for example if the application is python or dotnet, the way it is current in the project should remember to change the python versions in both the Dockerfile and gitlab-ci file. What I don't like is that you end up handling everything with Docker-in-Docker.
What do you consider to be a best practice and why?