-
Notifications
You must be signed in to change notification settings - Fork 563
Allow progress also when saving to docker daemon #972
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
Conversation
Codecov Report
@@ Coverage Diff @@
## main #972 +/- ##
=======================================
Coverage 75.19% 75.19%
=======================================
Files 107 107
Lines 4837 4837
=======================================
Hits 3637 3637
Misses 669 669
Partials 531 531
Continue to review full report at Codecov.
|
@@ -54,15 +54,15 @@ func Tag(src, dest name.Tag) error { | |||
} | |||
|
|||
// Write saves the image into the daemon as the given tag. | |||
func Write(tag name.Tag, img v1.Image) (string, error) { | |||
func Write(tag name.Tag, img v1.Image, opts ...tarball.WriteOption) (string, error) { |
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.
It's a bit weird for daemon.Write
to take a tarball.Options
, it leaks a bit of the underlying abstraction.
Would it make sense to define a daemon Option for progress and convert it internally into the tarball Option?
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 that remote.Write has the same problem, due to WriteOptions being added on the wrong level
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.
But the right thing to do would probably be to add a daemon.WithProgress, instead of tarball.WithProgress
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.
Yeah exactly. #967 defines a new remote.WithProgress
. In the case of daemon
, it might end up using tarball.WithProgress
underneath, but it feels weird to have that leak into its API.
There isn't a daemon.WriteOption
type yet, but I think we could add one, and a daemon.WithProgress
that implements it, that converts to a tarball.WriteOption
internally.
@jonjohnsonjr wdyt?
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.
Otherwise it seems to be working, of course we might end up using tarball anyway for Podman support.
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've stomped on this PR a little bit by making everything just daemon.Option
(sorry), but it shouldn't be too hard to do this now by just translating the daemon.WithProgress
into a tarball.WithProgress
.
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 had to fork everything anyway, to make a podman
matching the daemon
in the API.
It seems like this internal "temporary archive" also breaks the digest, which is reset to Our patched go-containerregistry does allow it in the reference, but docker doesn't load it.
This means that
Which breaks our check, which tries to check both tag and digest. I added* an extra ImagePull So it will first do the ImageLoad (from stdin), and then do ImagePull - only pulling the manifest * 761f6f9 |
This Pull Request is stale because it has been open for 90 days with |
The initial implementation only added progress to tarball
Fortunately the daemon Write uses a temporary tarball file