chore: refactoring docker system

[albttx]

No description provided.

[tbruyelle]

Let's not have a default value here. I assume without it the gh action will fail because it currently relies on it, but this is not what we want. We want the GO_VERSION to match the version declared in the go.mod, like in make docker-build-debug.

Probably the simplest way to handle this is to call make docker-build-debug in the gh action (or maybe use an alias make docker-build).

[albttx]

Mhhh, i don't like not having value here, because a simple docker build -t my-img . would fail

[albttx]

Or we can move the -alpine in the makefile, and have by default alpine which will take the latest go version ?

[tbruyelle]

Mhhh, i don't like not having value here, because a simple docker build -t my-img . would fail

Yes, and it's not a problem per say.

The problem here is if we upgrade the go version in the go.mod, the docker build will fail because the make install command will return an error because the go versions (docker image and go.mod) does not match.

In other words, if we upgrade the go version in the go.mod, we also have to change this ARG here, and this is what I want to avoid.

Maybe it is possible to guess the go version in a preliminary stage of the docker file, where go list -f {{.GoVersion}} -m is executed just like in the Makefile. If yes then we don't need that ARG. But I'm not sure it is possible to define ARG with executed content inside the docker file.

[tbruyelle]

Or we can move the -alpine in the makefile, and have by default alpine which will take the latest go version ?

But the go version of the docker build must match the go of the go.mod, like the restriction we have in the makefile. I don't understand why do you want to ignore the restrictions.

[albttx]

Ok, i've updated this way :)

[tbruyelle]

Thank you, but I think the gh action needs to be updated accordingly. The step docker/build-push-action@v5 will not feed the GO_VERSION arg I suppose. Is there a way to test this gh action?