Syncs last two minor versions of go when building internal images#387
Syncs last two minor versions of go when building internal images#387codefromthecrypt merged 2 commits intomasterfrom
Conversation
This prepares for #387 by looking up the homedir of the docker user dynamically. This also deduplicates runner configuration. Signed-off-by: Adrian Cole <adrian@tetrate.io>
codefromthecrypt
force-pushed
the
new-dockerfile
branch
from
5839457 to
90adf71
Compare
|
it isn't likely go 1.18 will be out before February based on release cadence, but I'll do this anyway as otherwise I'll forget all the context. https://golang.org/doc/devel/release |
codefromthecrypt
changed the title
codefromthecrypt
force-pushed
the
new-dockerfile
branch
from
bfb3bfa to
39484ab
Compare
Syncing the last two versions of go (installed on the GHA runner) allows PRs to choose go 1.18 once it is available and not have a race-condition publishing Docker images. This unsets GOROOT for consistency with GitHub Actions runner. We don't need this because Makefile manages version selection. Signed-off-by: Adrian Cole <adrian@tetrate.io>
codefromthecrypt
force-pushed
the
new-dockerfile
branch
from
39484ab to
2ff059c
Compare
codefromthecrypt
changed the title
Signed-off-by: Adrian Cole <adrian@tetrate.io>
| # Setup ENV variables used in make that match the GitHub Actions runner. | ||
| ENV RUNNER_TOOL_CACHE ${runner_tool_cache} | ||
| ARG go_stable_release | ||
| ENV GOROOT_${go_stable_release}_${arch} ${goroot_stable} |
There was a problem hiding this comment.
Most of the complexity here is caused by lack of variable substitution. ENV can only be build from build args. To change GOROOT_1_17_X64 into GOROOT_1_17_ARM64, we have to break GOROOT_1_17_X64 into 1_17, X64 then substitute arch with build args. If substitution worked, we could do replacement instead.
Another option I thought about but dismissed was manually building the multi-architecture image with manifest. In that way, you could pass different build args per platform, effectively resolving them externally. I did that before in Zipkin https://github.com/openzipkin/docker-alpine/blob/master/build-bin/docker/docker_push
However, I think most people don't understand manifests and it would be easier to understand if buildx was used even if it implied some complexity in the Dockerfile. Especially that there's >0 chance moby will add substitution.
1 participant
Syncing the last two versions of go (installed on the GHA runner) allows
PRs to choose go 1.18 once it is available and not have a race-condition
publishing Docker images.
This unsets GOROOT for consistency with GitHub Actions runner. We don't
need this because Makefile manages version selection.