-
-
Couldn't load subscription status.
- Fork 20
Refactor stability for Docker Image Updates #532
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.
Summary of Changes
Hello @thekop69, 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!
This pull request significantly improves the stability and accuracy of Docker image update detection. It addresses a fundamental issue where the system's previous reliance on the order of digests in RepoDigests led to unreliable update notifications. The core change involves fetching the latest image digest and then checking for its existence within the entire list of digests associated with the currently installed image, rather than assuming its position. This refactor ensures that update checks are more robust and eliminates false positives, providing a more reliable experience for users monitoring Docker image versions.
Highlights
- Improved Docker Image Update Stability: The primary goal of this PR is to enhance the reliability of Docker image update detection. It addresses a flaw where the system incorrectly assumed the currently installed image's digest would always be the first entry in the
RepoDigestslist, leading to false positives for available updates. - Refactored Digest Comparison Logic: The logic for determining if an image is up-to-date has been refactored. Instead of comparing a fetched
newDigestwith a presumedoldDigestfrom the firstRepoDigestentry, the system now fetches thenewDigestand then verifies its presence within the entireRepoDigestsarray of the installed image. - Enhanced Image URL Parsing: The
getImageUrlmethod withinDockerhubAdapter.tshas been made more robust. It now correctly handles various image naming conventions, including official Docker library images (e.g.,nginx), images with explicit registry prefixes (e.g.,docker.io/user/image), and standard user images. - Simplified API for Digest Checks: The
checkForNewDigestmethod across allImageRegistryAdapterimplementations (Dockerhub, Github, Lscr) has been simplified. It now returns only thenewDigeststring, as theisDifferentboolean is no longer needed at this level of abstraction. - Fix for False Image Updates: As a beneficial side effect, this refactor resolves an issue where
MqDockerUpwould incorrectly report false image updates, improving the accuracy of update notifications.
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 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. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.
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.
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 is a great initiative to improve the stability of Docker image update checks by correctly handling RepoDigests. The core logic change to check for the existence of the new digest among local digests is sound. The refactoring of getImageUrl in DockerhubAdapter to better handle various image name formats is also a good improvement.
I've identified a few areas for improvement, mainly in HomeassistantService.ts, where some edge cases (like an empty repoDigests array) could lead to incorrect behavior. I've also suggested re-adding a helpful warning message that was removed from DockerhubAdapter.ts. My detailed comments and suggestions should help make this refactoring even more robust.
|
Thanks for you great contribution everything you have mentioned make sense and im gonna create a new version very soon. Since i have not had much time in the past few weeks im really happy to see you contribution to fix some deeper issues. Im also experiencing the bug we have after restart/update. This is caused due to the new container id not matching with the old one. So MqDockerUp tries to access the old id which is non existant. |
|
No worries, and the container ID mismatch is exactly as you describe. If I get some time, I'm happy to put a PR together for it and you might be able to roll out a new version with both the fixes. |
This is a small refactor of the Docker image updates. Please review and test, I have made these changes and the Docket image updates are more stable now
Firstly, thanks for creating this, having recently migrated my HA to an Intel NUC running Docker, I came across this and found the immediate benefits.
What I did find however is some stability issues in when Docker image updates might appear. Hopefully the below adds some clarity on the changes I've made in this PR that you may wish to merge in. I've built and tested these changes on my own set up and can confirm they're working.
docker.io/grafana/grafana latest sha256:57bdc141f3f0ac32c2148d0f190cda8406c230f26cf0ec9ea3f33c274b145eb9 dea451b948c6 36 hours ago 740 MBThe current way of knowing what the currently installed digest is to take the first index in RepoDigests:
"RepoDigests": [ "docker.io/grafana/grafana@sha256:57bdc141f3f0ac32c2148d0f190cda8406c230f26cf0ec9ea3f33c274b145eb9", "docker.io/grafana/grafana@sha256:eba36967202bb8fc58404849e58ce10eb12a45cf70370ba483785295f0697da1" ],However, what I observed is that there's no guarantee that the installed digest always appears as the first element. As you can see from the eclipse-mosquitto example below:
`docker.io/library/eclipse-mosquitto latest sha256:d219d3a72847f3aed6a1d66975972d3b17f86e39e8f6f6b86b4088b879c1a2d6 42292b8c6592 4 weeks ago 11.3 MB
"RepoDigests": [
"docker.io/library/eclipse-mosquitto@sha256:338276c00dc691eb9c59ac730d874638508073fc1ebe4c4cc957b154a37705bf",
"docker.io/library/eclipse-mosquitto@sha256:d219d3a72847f3aed6a1d66975972d3b17f86e39e8f6f6b86b4088b879c1a2d6"
],
`
What happens in this latter example is that in HA, you will always get told there's a new update. Dockerode doesn't unfortunately provide the Digest itself so what this refactor does is to get the new digest first and then check for the existence of the new digest in the RepoDigest object. This feels a much more stable way to check whether there's a new digest available for updating from within HA.
This also inadvertently fixes MqDockerUp from a false image update. There's a crash that I currently observe when a container tries to restart after an update because the container ID no longer exists - I'll have a separate PR up for that once I've dug into it.
Feedback welcomed.