-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Adds flag modifying pull behavior for running and creating containers #1498
Conversation
Hey docker folks. This is my first PR to the project (👋 ). It's likely deficient on tests (I especially wasn't sure about any kind of integration or e2e testing that needed to happen. Let me know what ya'll think. |
0934964
to
58517d0
Compare
Codecov Report
@@ Coverage Diff @@
## master #1498 +/- ##
==========================================
+ Coverage 56.75% 56.77% +0.01%
==========================================
Files 309 309
Lines 21658 21668 +10
==========================================
+ Hits 12292 12301 +9
+ Misses 8469 8468 -1
- Partials 897 899 +2 |
Nice work. I hope the docker folks will merge this. |
a43abec
to
05ecd71
Compare
Please sign your commits following these rules: $ git clone -b "34394-run-pull-flag" git@github.com:Zanadar/cli.git somewhere
$ cd somewhere
$ git rebase -i HEAD~842354135168
editor opens
change each 'pick' to 'edit'
save the file and quit
$ git commit --amend -s --no-edit
$ git rebase --continue # and repeat the amend for each commit
$ git push -f Amending updates the existing PR. You DO NOT need to open a new one. |
f31fec0
to
053b7b4
Compare
Using the pull command explicitly until the docker CLI supports this natively. re docker/cli#1498 [#162511937]
What's the work remaining in order to get this merged? |
AFAIK nothing (but it’s been a while since I opened this so I may have forgotten). Maybe project folks have a different opinion? |
@GordonTheTurtle could you take a look? |
@Zanadar can you try to increase the test coverage, you are slightly falling short, as per the above Check. I would love to see this feature merged, it is really useful! |
Overall this looks good, but I think we can clean up the implementation a bit. |
Also keep in mind pull-policy=always only really works for moving tags (such as |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we error out early if pull=always and the pull failed?
cli/command/container/create.go
Outdated
@@ -194,31 +205,59 @@ func createContainer(ctx context.Context, dockerCli command.Cli, containerConfig | |||
} | |||
|
|||
//create the container | |||
response, err := dockerCli.Client().ContainerCreate(ctx, config, hostConfig, networkingConfig, opts.name) | |||
var response container.ContainerCreateCreatedBody | |||
if opts.pull == PullImageMissing { // Pull image only if it does not exist locally. Default. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can do this flow and it will clean up quite a bit:
warning, psuedo-code:
if PullImageAlways {
pull()
}
err := createContainer()
if IsNotfound(err) && PullImageMissing {
pull()
}
createContainer()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Latest commit improves the flow per suggestion, but I'm not sure I've got it quite right...will work at it a bit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One thing I'm not certain on is whether we should error in the case that the image is not found locally and the "never pull" option is selected? In which case the flow becomes more like so:
if PullImageAlways {
pull()
}
err := createContainer()
if err {
if IsNotfound(err) && PullImageMissing {
pull()
createContainer()
}
return err // we won't be pulling so just return whatever err we got
}
This also saves trying to create the container twice in the "never pull" case (ie only try to create again in the case where we might pull).
That's probably something that would have to be left to users, though, right? We can't necessarily know whether a tag is moving or not. |
Right. |
f0b476c
to
a281095
Compare
This is now handled in the first block: https://github.com/docker/cli/pull/1498/files#diff-477f60a1b609e77fdca573fd8bd7b0c9R210 |
@cpuguy83 Okay I cleaned things up a fair bit. I'd love a review pass on the tests and your thoughts on how we handle the error case when "never pull" is selected (see above). |
Is there a reason why the latest version of Docker Desktop on Windows still has version 19.03 of the CLI? According to this thread it seems 19.09 should've been worked on/ready for about 6 months already. |
Could the default behaviour be overriden by an env var? I could come up with a PR. |
This is still not available in engine version 19.03.08 in Docker for Mac. Any estimate when this will be available? |
Next release (20.xx) |
Two (stupid?) questions:
e.g.
|
I don't understand your first one. |
Jut got a new version of Docker Desktop for Windows which includes a new version.... 19.03.13 Is 19.09 ever coming to Windows too? |
Docker version 19.09 added some new pull logic[1] to the run command that could be used here [1]: docker/cli#1498
Docker version 19.09 added some new pull logic[1] to the run command that could be used here [1]: docker/cli#1498
- docker-compose doesn't automatically pulll latest container versions, which can result in unexpectedly old containers being used - Despite requests for years to add this support to docker-compose it hasn't been added. see: docker/compose#3574 - Eventually this will make its way in as part of the work in docker/cli#1498
Should close issue moby/moby#34394
- What I did
--pull
flag todocker run
anddocker create
, following the proposal in (Proposal: add explicit "--pull" flag to "docker run" for controlling image pulling behavior moby/moby#34394)--pull=missing
(this is the current behaviour and will be the default.)--pull=never
--pull=always
- How I did it
createOptions.pull
which forks the execution ofcontainer.createContainer
to either pull the image if it does not exist at all locally--pull=missing
, always try and update the image--pull=always
, or never try and update the image, only using images that already exist on the local machine--pull=never
Both
docker run
anddocker create
can consume this flag.- How to verify it
docker run
anddocker create
with the flag. Notice that pulls images or does not, depending on the behavior specified in the flag. Running those commands without the flag should maintain the current behavior.- Description for the changelog
Adds flag modifying pull behavior for running and creating containers (Pull if Missing, Pull Always, Pull Never)
- A picture of a cute animal (not mandatory but encouraged)