When I run the command,
gcloud builds submit --tag gcr.io/[MY_TAG]
it builds the image and returns a success message.
However, when I run
docker run gcr.io/[MY_TAG]
I get an error on a line of a file that did exist before but I removed it and replaced it with something else.
I'd appreciate it if you give me some ideas on possible scenarios that gcloud builds submit
may not update a file and how to force it to update the file in the image.
Note that I do not have .gcloudignore
anywhere in my folder, the file that is not updated does not exist in .gitignore
, and I'm not able to use --no-cache
because it says:
ERROR: (gcloud.builds.submit) Invalid value for [no-cache]: Cannot specify --no-cache if builds/use_kaniko property is False
I checked the last log file generated in gcloud\logs\
and the file that I need to update is indicated as "Added"!
It may be that you're depending on the
latest
tag to disambiguate image versions but this does not work as expected.When you
docker run ... ${IMAGE}:latest
on your host, if the tag exists locally, whatever image has the tag, will be run. It is possible that the GCR:latest
is being updated but you're not using that when you run what your host has as:latest
.Tags are a flawed mechanism for identifying container images. Tags are commonly used to denote versions|releases but they are, in fact, arbitrary labels and afford little by way of any guarantee.
You're much better off using digests as these are unique (for unique images)
If we submit the build again, the
:latest
tag will jump to the new image:You may run a container from a specific image digest this way:
An alternative approach that depends upon you using distinct tags (and is not as good as using virtually-guaranteed-to-be-distinct digests) is:
NB Because we've been judicious, we have distinct digests for distinct tags. However, if we were to inadvertently reuse
v4
, different copies of the image would once again be inconsistent:Let's pull the image that currently (!) corresponds to
:v4
:Build the image reusing (!)
:v4
and pull it again:NB How the
:v4
tag has jumped to the new digest (e128...
).But, the image with
:v4
tag locally is the old image (5946...
).It's only when we (remember to) pull the
:v4
tagged image again that we'll pull what's currently tagged as:v4
on GCR.NB Same tag (
:v4
) but the digests (a hash) are unique to image builds.