You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As of podman 5.2, the behavior of podman build --pull changed to a no-op. Per docker (and previous podman releases), when --pull is not specified images should only be pulled if missing, if it is specified then it should always pull. This can be worked around by qualifying --pull=always explicitly.
However, podman's behavior around this flag does not appear to have been changed but rather the inherited flag from buildah seems to be at fault. Specifically it looks like pull request #5583 was intended to be a documentation only change but accidentally functionally changed --pull from the docker compatible meaning of --pull=always to being a no-op with the default behavior. It seems there was a misunderstanding that --pull string[="true"] is trying to communicate that if the =true part isn't specified than true would be used not that it's the default when --pull isn't present (the value for which is at the end of the help text itself and is currently the correct value).
Reverting that change fixes the issue, but should probably read "always" instead of "true".
Of note, podman's code has had the DefValue property changed to "missing" to correct a similar documentation issue there. Not NoOptDefVal. I believe this got mirrored in buildah by the same author in changeset 5afd52f.
Steps to reproduce the issue:
Create Containerfile with a FROM ... line.
Run podman build -f Containerfile multiple times and note that it only pulls if missing.
Add --pull to the command and note that the image is still only being pulled if missing instead of behaving like --pull=always.
Output of podman version if reporting a podman build issue:
Description
As of podman 5.2, the behavior of
podman build --pull
changed to a no-op. Per docker (and previous podman releases), when--pull
is not specified images should only be pulled if missing, if it is specified then it should always pull. This can be worked around by qualifying--pull=always
explicitly.However, podman's behavior around this flag does not appear to have been changed but rather the inherited flag from buildah seems to be at fault. Specifically it looks like pull request #5583 was intended to be a documentation only change but accidentally functionally changed
--pull
from the docker compatible meaning of--pull=always
to being a no-op with the default behavior. It seems there was a misunderstanding that--pull string[="true"]
is trying to communicate that if the=true
part isn't specified than true would be used not that it's the default when--pull
isn't present (the value for which is at the end of the help text itself and is currently the correct value).Reverting that change fixes the issue, but should probably read "always" instead of "true".
Of note, podman's code has had the
DefValue
property changed to "missing" to correct a similar documentation issue there. NotNoOptDefVal
. I believe this got mirrored in buildah by the same author in changeset 5afd52f.Steps to reproduce the issue:
FROM ...
line.podman build -f Containerfile
multiple times and note that it only pulls if missing.--pull
to the command and note that the image is still only being pulled if missing instead of behaving like--pull=always
.Output of
podman version
if reporting apodman build
issue:Output of
cat /etc/*release
:Output of
uname -a
:The text was updated successfully, but these errors were encountered: