Reputation: 439
I'm using Gitlab-CI to build some Docker images in a docker-in-docker image. This is significant only because every build uses a new docker-in-docker environment with an empty Docker cache. It is possible to cache the cache in Gitlab and restore it later, but that does not appear safe--someone on the Web did it--but that does not seem safe.
I have a Docker registry in Nexus I have used successfully for pulling and pushing.
I have also set up saving images into Gitlab-ci's cache with docker save
and loading from cache with docker load
.
With either pulling from the registry or loading from the Gitlab-CI cache, I can then run docker build --cache-from ...
and Docker will build incrementally, not rebuilding any layers of images that have not changed.
All built images get the latest
tag.
The part that does not work is this: If I load an image from the Gitlab-CI cache, then pull from the registry, the image from the registry is always used as the from Docker's point-of-view, even if it is weeks older than the one loaded from cache. This seems like defective behavior--to say the least, it is highly unexpected and undocumented as far as I can tell.
How can I tell Docker to:
1) use the later latest as the latest (alternatives without the latest
tag are a possibility), and
2) only download layers that have changed since what was loaded into Docker's cache?
That's 2 questions, but I'm hoping they have the same answer.
Upvotes: 0
Views: 79
Reputation: 1137
OK, if you mean yourimage:latest
, the latest
means nothing because it is only a convention and not a guarantee that you are really pulling the literally latest (newest) image.
If you load an image yourimage:latest
from local and afterwards you pull the same named image from a registry (yourimage:latest
) the last one will be the timely latest
. Because it is different from the first one even if the first one would be the timely newer one. If it has another fingerprint, it will be overwritten.
Upvotes: 1