-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Quadlet [build] generates invalid Pull
command lines
#24599
Comments
Thanks for reporting this. You are correct. I'm looking into what is the correct way to address this in the code |
Looks like the underlying root cause is spf13/cobra#866 I think we need to handle the |
Yes you are correct on both counts. I was trying to see if I can find a solution that does not need to single out this parameter from the rest. But, not sure that I can. The root cause of the difference between I was wondering whether the fix should be in WDYT? |
Yes I think we must keep it for backwards compat for now so we must split this out and handle it extra |
Issue Description
When applying
Pull=...
option in[build]
section via quadlet, the generated command line has the format--pull ...
format instead of--pull=...
format, which is supposedly not supported by buildah.Currently, I have to use
PodmanArgs=--pull=...
to avoid this issue.Steps to reproduce the issue
.build
file withPull=newer
(newer is a valid pull policy), in rootless podman.systemctl --user show -pExecStart
for the generated build unit.Describe the results you received
The generated
ExecStart
command is--pull newer
instead of--pull=newer
, which causes ambiguity in parsing.Describe the results you expected
The generated command should be
--pull=newer
.Since
podman build
also supports--pull
as a bare key, I am not sure how to support this in a quadlet file.podman info output
Podman in a container
No
Privileged Or Rootless
Rootless
Upstream Latest Release
Yes
Additional environment details
Additional environment details
Additional information
Additional information like issue happens only occasionally or issue happens with a particular architecture or on a particular setting
The text was updated successfully, but these errors were encountered: