Closed AstraLuma closed 3 years ago
Note that podman pull
does always check the registry (eg podman pull --creds not:valid debian
will always fail).
@astronouth7303 thanks for the issue. Just to make sure I'm on the same page, you used for the creds in the example not:valid
but when running the test you used valid creds right? I just want to make sure the creds aren't wrapped up into this somehow. Out of curiosity, did you try creating a Dockerfile with these contents:
FROM debian
and then doing buildah bud --layers --pull-always .
and podman build --pull-always .
?
I think those should be equivalent and should pull the image.
@astronouth7303 thanks for the issue. Just to make sure I'm on the same page, you used for the creds in the example
not:valid
but when running the test you used valid creds right? I just want to make sure the creds aren't wrapped up into this somehow.
Nope! The point was to use invalid credentials so that if the pull did hit a server, it would cause an error. buildah pull --creds not:valid
will succeed if the image already exists, implying that the registry never checked the credentials (because if it had, it would have rejected them and the pull will fail).
I also used strace
to validate that buildah wasn't making internet connections.
... and then doing
buildah bud --layers --pull-always .
andpodman build --pull-always .
?I think those should be equivalent and should pull the image.
Yeah, those will force the pull, with bad ux. They're just kinda awkward and involve a bunch of work (make a tempdir, write out Dockerfile, run bud, parse output, cleanup).
The context of this request is that I'm working on code to cache a build environment: Pull a base image, install packages, tag based on the requested packages for later use. I would like to implement a policy where I pull a fresh upstream version and see if it's changed.
(And the context for that is that I'm currently doing containerized builds on a Raspberry Pi, where IO is painfully slow, so even just spinning up extra containers has measurable performance impact.)
Note that the other use of buildah pull
could be "Resolve this image name into an ID", because it outputs just the ID and you don't need to do additional parsing.
buildah inspect
also does this, just outputs a big JSON blob instead of a single line. The usability of this varies dramatically based on how you're calling buildah. (eg, Python is easy. Bash would need jq
.)
@TomSweeneyRedHat Are you still looking at this one? Is the rework on podman pull enough to satisfy @astronouth7303 needs?
@rhatdan I've not gotten back to this. We could sping this off to someone else if you want.
This is fixed, I believe in the current podman(3.0) and Buildah 1.19.3.
Description
Currently there does not seem to be a way to force
buildah pull
to go an check a registry for a fresh copy of a container.Steps to reproduce the issue:
buildah pull --creds not:valid debian
strace buildah pull debian
buildah pull --help
Describe the results you received:
None of these give any indication that
buildah pull
will perform network activity if the image is already available locally.Describe the results you expected:
An option (eg
--force
or--always-check
) to go and check a registry, even if the image is available locally.Output of
rpm -q buildah
orapt list buildah
:Output of
buildah version
:*Output of `cat /etc/release`:**
Output of
uname -a
:Output of
cat /etc/containers/storage.conf
: