Docker Args

This is a short post I want to publish for spending about an hour for weird docker arg issue.

I used the following Dockerfile:

ARG dockerCacheRepo
FROM ${dockerCacheRepo}python:3.12-slim

Then I run the docker build command:

docker build --progress=plain --build-arg dockerCacheRepo=my-repo.com/  .

An indeed I see the argument is used:

#2 [internal] load metadata for my-repo.com/python:3.12-slim

But then I want to use the argument in other locations in the Dockerfile, for example:

ARG dockerCacheRepo
FROM ${dockerCacheRepo}python:3.12-slim
RUN echo "arg is ${dockerCacheRepo}"

But I get:

#0 building with "default" instance using docker driver

#1 [internal] load build definition from Dockerfile
#1 transferring dockerfile: 134B done
#1 DONE 0.0s

#2 [internal] load metadata for my-repo.com/python:3.12-slim
#2 DONE 0.1s

#3 [internal] load .dockerignore
#3 transferring context: 2B done
#3 DONE 0.0s

#4 [1/2] FROM my-repo.com/python:3.12-slim@sha256:85824326bc4ae27a1abb5bc0dd9e08847aa5fe73d8afb593b1b45b7cb4180f57
#4 CACHED

#5 [2/2] RUN echo "arg is ${dockerCacheRepo}"
#5 0.186 arg is
#5 DONE 0.2s

What?

Why is the argument reset?

After banging my head in the wall for a while I've found the working version:

ARG dockerCacheRepo
FROM ${dockerCacheRepo}python:3.12-slim
ARG dockerCacheRepo
RUN echo "arg is ${dockerCacheRepo}"

And then:

#0 building with "default" instance using docker driver

#1 [internal] load build definition from Dockerfile
#1 transferring dockerfile: 155B done
#1 DONE 0.0s

#2 [internal] load metadata for my-repo.com/python:3.12-slim
#2 DONE 0.6s

#3 [internal] load .dockerignore
#3 transferring context: 2B done
#3 DONE 0.0s

#4 [1/2] FROM my-repo.com/python:3.12-slim@sha256:85824326bc4ae27a1abb5bc0dd9e08847aa5fe73d8afb593b1b45b7cb4180f57
#4 CACHED

#5 [2/2] RUN echo "arg is my-repo.com/"
#5 0.137 arg is my-repo.com/
#5 DONE 0.2s

This is real bad design in docker.

The idea is that any arg that is configured is forgotten after the "FROM" command, and then it must be redefined. I guess the designers has a multi-stage docker build in mind when planning this, but i think this is a mistake. Anyway, I hope this saves some time for anyone who bumps into the same issue.