-
-
Couldn't load subscription status.
- Fork 20
Improve docker pull progress aggregation #497
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
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.
Hello @MichelFR, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
Summary of Changes
Hello team, gemini-code-assist here to provide a summary of this pull request by @MichelFR. The main goal of this PR, as indicated by the title and description, is to improve the accuracy and reliability of the progress reporting when pulling Docker images. The changes focus on refining how individual layer progress is tracked and aggregated to provide a more accurate overall percentage during the pull operation.
Highlights
- Improved Docker Pull Progress Aggregation: The logic for tracking and aggregating the progress of individual Docker layers during a pull operation has been enhanced. This includes better handling of events where progress details might be partial and explicitly marking layers as complete based on their status, leading to a more accurate overall progress percentage.
Changelog
- src/services/DockerService.ts
- Refined the event handling logic (around line 333) to process events based on layer ID even if
progressDetailis initially absent, ensuring all layers are tracked. - Modified how layer progress is updated (around line 336), ensuring existing progress is retained and updated conditionally based on available details in the event.
- Added logic (around line 341) to explicitly mark layers as 100% complete when their status is "Pull complete", "Download complete", or "Already exists", ensuring completed layers contribute fully to the total.
- Ensured the final percentage calculation (around line 351) does not exceed 100% using
Math.min.
- Refined the event handling logic (around line 333) to process events based on layer ID even if
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Layers start to pull,
Progress bar begins to fill,
Image now complete.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
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.
Code Review
This pull request aims to improve the aggregation of Docker pull progress, which is a valuable enhancement. The changes introduce more robust handling for layer progress updates, including initialization of new layers and special handling for completion statuses like "Pull complete" and "Already exists". The addition of Math.min(100, ...) for percentage calculation is also a good safeguard.
However, there's a significant concern regarding how layer.current and layer.total are updated when the incoming event.progressDetail contains a 0 for these values. The current logic might prevent progress from being correctly set to 0 if it was previously non-zero.
Summary of Findings
- Incorrect progress update with zero values: The logic
newValue || oldValuefor updating progress metrics (current/total bytes) does not correctly handle0as a validnewValue. If an event reports0bytes, the metric will retain itsoldValueifoldValuewas non-zero, leading to inaccurate progress display. This should be changed to directly usenewValueif it's defined, even if it's0.
Merge Readiness
The pull request introduces several good improvements to Docker pull progress reporting. However, there is a high-severity issue identified in how progress values of 0 are handled, which could lead to incorrect progress aggregation. I recommend addressing this issue before merging. As an AI, I am not authorized to approve pull requests; please ensure further review and approval from team members once the suggested changes are made.
| if (event.progressDetail && (event.progressDetail.current || event.progressDetail.total)) { | ||
| layer.current = event.progressDetail.current || layer.current; | ||
| layer.total = event.progressDetail.total || layer.total; | ||
| } |
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.
The current logic for updating layer.current and layer.total using event.progressDetail.current || layer.current (and similarly for total) can lead to incorrect progress reporting if event.progressDetail.current (or total) is explicitly 0.
For example, if layer.current is 50 and an event arrives with event.progressDetail.current: 0, the expression 0 || 50 evaluates to 50. This means layer.current would not be updated to 0, and the progress would inaccurately remain at 50.
Progress values of 0 are valid and should update the state. Consider updating these properties only if the new value is explicitly provided in event.progressDetail (i.e., not undefined), allowing 0 to be a valid update.
How about refining the update logic to ensure 0 is treated as a valid new value from event.progressDetail?
| if (event.progressDetail && (event.progressDetail.current || event.progressDetail.total)) { | |
| layer.current = event.progressDetail.current || layer.current; | |
| layer.total = event.progressDetail.total || layer.total; | |
| } | |
| if (event.progressDetail) { | |
| if (event.progressDetail.current !== undefined) { | |
| layer.current = event.progressDetail.current; | |
| } | |
| if (event.progressDetail.total !== undefined) { | |
| layer.total = event.progressDetail.total; | |
| } | |
| } |
Summary
Testing
npm testhttps://chatgpt.com/codex/tasks/task_e_6840cc1723788329b1a329f33feeb381