-
Notifications
You must be signed in to change notification settings - Fork 509
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
[proposal] implement pull-policies (docker build --pull=missing|never|always) #1889
Comments
@tonistiigi wdyt? |
Hey @thaJeztah,
How does this sound to you? |
actually, the last one is one I didn't look at. Likely a "corner case", but wondering if it would be less surprising if
We may have to look at @tonistiigi @AkihiroSuda any thoughts? |
#1889 looks perfect. |
Fwiw, this would be a breaking change unless you really carefully implement it as described above. We've just been bitten by the argument parsing of
(I opened docker/cli#3681 about this) |
I'm not sure if the CLI library allows updating this in backward compatible way but assuming it does:
This would require BuildKit change. There is no current ResolveMode implementation with these semantics. What's missing from the list is the "fallback mode" (not sure what would be the correct name) that is the default in buildkitd without docker imagestore. In this mode, you always get the latest version of the image, but you can still use local images as well. If the build fails because there is no remote image with that name or you don't have an active network connection, then it will fall back to using a local version of the image. |
No matter what I believe it would be nice to have a similar syntax between
|
Honest answer: "close", but not fully. We did this for But there's one exception that we overlooked; |
In either case, I think this ticket would now better be in the |
Pull request docker/cli#1498 added a
--pull
option todocker run
anddocker create
(to address moby/moby#34394), which allows the pull-policy to be configured to use, and has three options:--pull
--pull=missing
--pull=never
--pull=always
produce an error if pull failed
docker build
also has a--pull
flag, but is implemented as a boolean:--pull
--pull=false
--pull / --pull=true
produce an error if pull failed. This is the equivalent of
--pull=always
ondocker run
Proposal
I think it would make sense to have
docker build
support the same options asdocker run
. For backward-compatibility,--pull
would be the equivalent of--pull=always
:--pull
--pull=missing
--pull=never
--pull=always
produce an error if pull failed
--pull
--pull=always
. kept for backward compatibilityThe text was updated successfully, but these errors were encountered: