Changing the base image from docker:28.5.2 to docker:29.0.0 breaks our Dockerfile #562
Replies: 1 comment 5 replies
-
In the future, I would suggest you investigate before reporting. 😅 After you've done some investigation, feel free to come back and we can perhaps offer more guidance when you have more information about what's happening. |
Beta Was this translation helpful? Give feedback.
-
|
I understand. My intention was simply to report a behavioral change in Docker that breaks a previously working build when upgrading from 28.5.2 to 29.0.0. Whenever a version bump introduces a regression on our end, I feel it's appropriate to provide a minimal reproducer and notify the project, but my involvement generally stops there. If there's difficulty running the reproducer, I’m happy to help with that part. Otherwise, I don’t plan to investigate the internals further — it’s ultimately not something I can allocate time to, especially since our current workaround is to stay on the older base image. Just wanted to make sure the team was aware of the change in case it’s useful. |
Beta Was this translation helpful? Give feedback.
-
|
If I'm being frank, your Given it was vibe-coded, perhaps providing your original input would be helpful to getting better suggestions for what you should be doing instead? |
Beta Was this translation helpful? Give feedback.
-
|
😖 Whoa. That is absolutely wild. Is that running the Which is just this: FROM nginx:1.29.3
COPY --from=nginx:1.29.3 /usr/share/ /usr/shareOr if perhaps the image modifies FROM nginx:1.29.3 as build
RUN set -eux; \
/docker-entrypoint.sh nginx -g 'daemon off' &; \
# wait for it to completely start up
# stop it
# ???
FROM nginx:1.29.3
COPY --from=build /usr/share/ /usr/shareComing back to the cause of the issue, I think the explanation is docker/cli#6646 (comment) |
Beta Was this translation helpful? Give feedback.
-
|
Thank you both for taking the time to respond! I'll try to clarify our use case a bit more. Our target image is relatively simple to create using
However, we do not like this approach:
As such, we tried to bridge the gap between these two. In our Dockerfile, we:
I hope this clarifies our use case, and would love to hear your thoughts on this. |
Beta Was this translation helpful? Give feedback.
-
|
Given that each If it does not, you'll want/need to get a shell from somewhere; here's a FROM scratch
RUN --mount=type=bind,from=busybox:uclibc,target=/tmp ["/tmp/bin/sh","-euxc","echo foo > /foo"](so you could replace |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Reproducer: https://github.com/jvanheesch/dockerfile-from-docker
Above minimal-ish reproducer contains a
Dockerfilethat starts fromdocker:28.5.2.It contains a
RUNinstruction that startsdockerd, waits for it to be ready, and then runs the following command:docker compose up -d && docker compose stop && docker compose cp nginx:/usr/share /test && docker system prune -fThe resulting output,
/test, is used in a subsequent stage.This approach works just fine, but breaks when we replace
docker:28.5.2withdocker:29.0.0.Running
./build.sh 2>&1 | catafter this version bump results in:I have not investigated what is going on, and truth be told, the whole setup was vibe coded. But given that it used to give us the image we wanted, and no longer does after version bump, I figured it's probably best to report nonetheless.
Beta Was this translation helpful? Give feedback.
All reactions