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 current/available image version #70
Comments
Thank you for a clear and detailed post! If you see my answers in this current FR: [FEATURE REQUEST] Add Link to GitHub repo #67 I'll keep digging in the future, but right now I've not got a clear idea for how to solve it. You can explore with commands like
Or To see how many tags (and unclear naming) there's for a specific image. And if you run this
You'll see how many of your current containers that don't have a version label and how different naming they use. Sorry for being negative - but this is how far I came when digging into this recently. I wont give up, but I don't have the time nor energy to invest further in this right now. |
Thank you for your detailed reply! That's just the situation in reality, no need to shoot the postman for the bad news 🙂 I was half afraid of that situation. Maybe we can still try to approach a working POC. It's two things that are required: the current version and the latest sane version label. If I understood your reply in the other post correctly then currently your algorithm works like this:
Now an attempt for a solution could work with the assumption the project uses semantic versioning. This regex could be used to filter out the sanitized tags from the registry:
The local version could be fetched by this command:
This of course requires the image to be reverenced by the precise version tag (e.g. Now what's left required is an algorithm which compares the two versions. This could be a bit tricky due to the fact that this project uses Bash. But there might be existing solutions for this. But maybe this isn't even required if only the tag of the image from What do you think? |
I'm glad that you keep on brainstorming and helps suggesting solutions!
Well currently this is it:
Then they're just compared, if the sha256:value from the newest exists in the local - it's already latest. So if you've got the version tag And if you're using
This is easily done once I've got two tags to compare. The hard thing is getting the tags extracted reliably - both from local images and from the registry. |
Just for reference the simplified process for a single docker container by its name: %%{init: {"flowchart": {"htmlLabels": false}} }%%
flowchart TD
classDef code fill:#bbf,stroke:#f66,stroke-width:2px,color:#fff,stroke-dasharray: 5 5
begin([BEGIN]) --> iterate
subgraph iterate["For each container by name"]
repourl["get image ($RepoUrl) by $name`"] --> local_hashes["get local hashes ($LocalHash) by $RepoUrl"]
repourl -.- repourl_example["mariadb:10.11.6"]:::code
local_hashes -.- local_hashes_example["[mariadb@sha256:692… mariadb@sha256:d86…]"]:::code
local_hashes --> remote_hash["get remote hash ($RegHash) by $RepoUrl"]
remote_hash -.- remote_hash_example["sha256:e84…"]:::code
remote_hash --> contains{"is remote hash within local hashes?"}
contains -- yes --> update["add name to updatable list ($GotUpdates)"]
contains -- no --> no_update["add name to non-updatable list ($NoUpdates)"]
end
iterate --> end2([END])
|
Would it be possible to include the current respectively the available image version in the list of images that have an update? Maybe even with a link to the releases page of that image, e.g.:
The version could be rendered like the version update notification for dockcheck itself (https://github.com/mag37/dockcheck/blob/main/dockcheck.sh#L149).
Rationale: For me this would be useful to safe a lot of time checking the version gap of the update. And I wouldn't update immediately when the raise is like from
2.13
to3.0
because I'd also wait for at least one or two point releases.The text was updated successfully, but these errors were encountered: