-
Notifications
You must be signed in to change notification settings - Fork 5.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rm
+ build
+ up
keeps using the previously existing image for a container (2.11.0)
#9856
Comments
Problem seems to have been introduced with 2.11.0 (perhaps #9819?). |
rm
+ build
+ up
keeps using the previously existing image for a containerrm
+ build
+ up
keeps using the previously existing image for a container (2.11.0)
It seems like to reproduce -
but if you run your container by
It seems like 2.11 require to use moby/buildkit and buildx and some new stuff, and lead to break some scenarios like (my GitLab CI loves it)
I started to see |
I have similar issue regarding
After some experiments I found that following workaround may help (but not in every build!):
|
Description
It seems that using a combination of
docker compose rm <CONTAINER>
+docker compose build <CONTAINER>
+docker compose up <CONTAINER>
does not tag a new image and therefore keeps using an old one when it exists.Only after calling
docker compose down --rmi local
ordocker rmi
will it then cause a new image to be tagged and used.From the output it's possible to gather that the "sending tarball" and "importing to docker" steps that should happen under normal circumstances, do not run when the problem occurs. Furthermore, passing the
--build
flag todocker compose up
seems to circumvent the problem.Steps to reproduce the issue:
Describe the results you received:
A new image is not tagged despite the build running and the project keeps using an older image until the image is explicitly removed via docker
compose down --rmi local
ordocker rmi
.output from the test described above
Describe the results you expected:
A new image to be tagged and used if the container changed.
Additional information you deem important (e.g. issue happens only occasionally):
This bug seems to have been introduced in 2.11.0, problem is not reproducible with earlier versions.
It seems that using the
--build
flag on the second docker compose up call (after docker compose build) does make the problem go away...Output of
docker compose version
:Output of
docker info
:The text was updated successfully, but these errors were encountered: