Skip to content
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

Show the total size and progress of the total downloaded size when pulling the image #47652

Open
ghorbani-ali opened this issue Mar 29, 2024 · 2 comments
Labels
area/ux kind/enhancement Enhancements are not bugs or new features but can improve usability or performance. status/0-triage

Comments

@ghorbani-ali
Copy link

ghorbani-ali commented Mar 29, 2024

Description

Hi
When we pull the images, nothing is displayed about the image size, how many layers are there, or how much is downloaded. This can be most user-friendly.

However, from my study of the contribution documents, I found that to start working on such a change, I need to get approval from your team first.

May I work on this? Any insight?

@ghorbani-ali ghorbani-ali added kind/feature Functionality or other elements that the project doesn't currently have. Features are new and shiny status/0-triage labels Mar 29, 2024
@thaJeztah thaJeztah added kind/enhancement Enhancements are not bugs or new features but can improve usability or performance. area/ux and removed kind/feature Functionality or other elements that the project doesn't currently have. Features are new and shiny labels Apr 4, 2024
@thaJeztah
Copy link
Member

Thanks for opening this ticket! We are planning to make overall improvements to various parts of the CLI (and API), which includes improvements to progress output such as on docker pull.

However, there's some substantial work to be done for this, and some of those changes will result in breaking changes. Unfortunately, some of the "streaming" responses used for progress-bars originate from very early on in the docker project, and these have not been well-defined / documented; as a result, many implementations using the API started to depend on the (sometimes undocumented) behavior, which makes it very risky to make changes.

Usually, we prefer making "granular" changes / improvements, but for this case, every small improvement could cause compatibility issues, and therefore we want to work on a more invasive, one-time, overhaul of these parts.

We have some internal tickets (at Docker), and some initial designs for improvements, but they are still being finalised before we'll be opening a proposal for changes. A placeholder ticket (but it's not yet very specific) can be found below;

I'll keep this ticket open as this is definitely part of the work that should be considered as part of the rewrite, but (as outlined above) we prefer not to make this change yet as a separate contribution, but rather as part of the change as a whole.

@ghorbani-ali
Copy link
Author

@thaJeztah Thanks for your reply. I just want to express my willingness to be apart of this process. If there is any possibility, let me know.

Bests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/ux kind/enhancement Enhancements are not bugs or new features but can improve usability or performance. status/0-triage
Projects
None yet
Development

No branches or pull requests

2 participants