Why void from load image command executed? Can't we return the official response result?

[vangogh-ken]

It's should be key information of loading an image into docker

HTTP/1.1 200 OK
Content-Type: application/json
Transfer-Encoding: chunked

{"stream":"Loaded image: busybox:latest\n"}

[TannerYoung]

This would be useful for my use case (loading an image from a tar file, then using test-containers). There are a couple of workarounds which are all annoying.

1. Know both the file path name and the resulting image name.
2. Know the file path name, run LoadImageCmd, and simultaneously untar the file and inspect the manifest.json programmatically. This introduces an unnecessary dependency on both untar and json parsing.

[babycoderz]

@vangogh-ken Hello, I have encountered the same problem now, need to get the return value of loadImageCmd, get the image name and tag. Is there any good solution?

[codeseedr]

Any plans on returning the identifier of the loaded image? It looks like a clear omission to me.

[codeseedr]

Seems like the command response does not include image ID... Reported the issue upstream: docker/cli#2212

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[codeseedr]

Bump.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[AgentOak]

Bump

[codeseedr]

Can I ask everybody interested in getting this fixed to thumb up/comment on the prerequisite docker issue: docker/cli#2212? Thank you!

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[codeseedr]

Lack of activity does not mean that the issue has become invalid. Or there's no one interested in getting it fixed.

[bsideup]

there's no one interested in getting it fixed.

If there is anyone who is willing to work on this they are more than welcome to!
Although there doesn't seem to be enough activity in the upstream issue

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[AgentOak]

Still not stale

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[codeseedr]

Bump.

[bsideup]

There is no point in bumping unless it gets implemented on the Docker API side:

docker/cli#2212 (comment)

[codeseedr]

What are the chances it gets implemented if the upstream issue eventually gets fixed but this one would have already been stale for a long time?

[bsideup]

There wilk be another "Support this new API" issue :)

[codeseedr]

OK, sounds good.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ghost]

This would be useful for my use case (loading an image from a tar file, then using test-containers). There are a couple of workarounds which are all annoying.

1. Know both the file path name and the resulting image name.

@TannerYoung - Mind sharing how you were able to accomplish this workaround? It seems pretty reasonable to me.

[vipingupta5352]

This would be useful for my use case (loading an image from a tar file, then using test-containers). There are a couple of workarounds which are all annoying.

1. Know both the file path name and the resulting image name.
2. Know the file path name, run LoadImageCmd, and simultaneously untar the file and inspect the manifest.json programmatically. This introduces an unnecessary dependency on both untar and json parsing.

@TannerYoung can you please share how did you implement this workaround.