Fix Docker image to specific Golang version #107
Conversation
.go_version
Outdated
| @@ -0,0 +1 @@ | |||
| 1.13.0 | |||
There was a problem hiding this comment.
@andrewkroh It would be nice if gvm would support something like gvm use and has a convention which file it uses. Perhaps there is already something like this but I missed it?
There was a problem hiding this comment.
You can run a command like gvm use $(cat .go-version) but there's nothing built-in for reading a file.
There was a problem hiding this comment.
WDYT about creating a "default" location for a file similar to what nvm use does. to get rid of the cat magic?
There was a problem hiding this comment.
I don't have an issue with such a feature as described for .nvmrc. But I also don't see a whole lot of extra value in it either since it's easy to read the file explicitly with a shell. It might help establish a convention for specifying the Go version in a project.
There was a problem hiding this comment.
I would expect it helps for cross stack compatibility. Will go for now with the shell version. Worth opening an issue in gvm?
There was a problem hiding this comment.
Definitely open an issue for it. 👍
| @@ -1,4 +1,4 @@ | |||
| FROM golang:latest | |||
| FROM golang:${GO_VERSION:-1.13.0} | |||
There was a problem hiding this comment.
If you want to force the version to come from an outside arg you could do
ARG GO_VERSION
FROM golang:${GO_VERSION}
and run docker build --build-arg GO_VERSION=$(cat .go_version) .
There was a problem hiding this comment.
Ups, missed the ARG line. That was exactly what I wanted to do.
ruflin
force-pushed
the
docker-goversion
branch
from
4baed54 to
16ab6c6
Compare
So far the `:latest` image was used for Golang. To be used in production I prefer to tied it to a very specific version so we know what is run and what we test is identical. A file `.go-version` was introduced which long term should serve as the single point of through for the go version, also for CI. At the moment it is only there for documentation purpose. The ENTRYPOINT of the Dockerfile was split up into ENTRYPOINT to make it easier to overwrite parameters. Note: As part of this change I also looked into using the alpine Golang image but it does not have Git included, which makes working with the Golang mod dependency trickier.
ruflin
force-pushed
the
docker-goversion
branch
from
16ab6c6 to
3078aa0
Compare
So far the
:latestimage was used for Golang. To be used in production I prefer to tied it to a very specific version so we know what is run and what we test is identical.A file
.go-versionwas introduced which long term should serve as the single point of through for the go version, also for CI. At the moment it is only there for documentation purpose.The ENTRYPOINT of the Dockerfile was split up into ENTRYPOINT to make it easier to overwrite parameters.
Note: As part of this change I also looked into using the alpine Golang image but it does not have Git included, which makes working with the Golang mod dependency trickier.