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 current/available image version #70

Open
thomas-mc-work opened this issue Feb 17, 2024 · 4 comments
Open

Show current/available image version #70

thomas-mc-work opened this issue Feb 17, 2024 · 4 comments

Comments

@thomas-mc-work
Copy link
Contributor

thomas-mc-work commented Feb 17, 2024

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 to 3.0 because I'd also wait for at least one or two point releases.

@mag37
Copy link
Owner

mag37 commented Feb 19, 2024

Thank you for a clear and detailed post!
While I agree this would be a very nice addition - it requires a lot of work and testing and I'm not really sure it's possible to achieve cleanly and consistently, due to the very different ways of handling tags.

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.
As you can see (from what you've linked) the naming of versions and how recent they are are not very clear or generic - so pretty hard to build logic to present it in a fail-safe way.

You can explore with commands like

curl --silent "https://registry.hub.docker.com/v2/repositories/linuxserver/wireguard/tags?page_size=100" |  jq -r ".results[].name" | sort --version-sort

Or regctl tag ls linuxserver/wireguard

To see how many tags (and unclear naming) there's for a specific image.

And if you run this

for i in $(docker ps --format '{{.Names}}') ; do printf "$i - " && docker inspect "$i" --format='{{ index .Config.Labels "org.opencontainers.image.version" }}' ; done

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.

@thomas-mc-work
Copy link
Contributor Author

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:

  1. hash = hashed digest of the image of a running container
  2. latest_hash = retrieve the latest tag of that image on its respective container registry (how do you know which one this is?)
  3. update_available = hash != latest_hash

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:

^(v?\d+(\.\d+)*(-.+)?)

The local version could be fetched by this command:

$ docker inspect netbox-redis-1 --format "{{ .Config.Image }}"
redis:6.2.7-alpine

This of course requires the image to be reverenced by the precise version tag (e.g. 6.2.7-alpine) instead of the magic latest.

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 latest_hash could just be shown.

What do you think?

@mag37
Copy link
Owner

mag37 commented Feb 22, 2024

I'm glad that you keep on brainstorming and helps suggesting solutions!

  1. hash = hashed digest of the image of a running container
  2. latest_hash = retrieve the latest tag of that image on its respective container registry (how do you know which one this is?)

Well currently this is it:
1.
docker image inspect "codeberg.org/forgejo/forgejo:1.20" --format '{{.RepoDigests}}'
Giving the result:
[codeberg.org/forgejo/forgejo@sha256:c2e782fdf876e4e7f179819a43b0e729aab59c37aa67a71d09f76dd2c7b2a214]

regctl image digest --list codeberg.org/forgejo/forgejo:1.20
Giving the result:
sha256:c2e782fdf876e4e7f179819a43b0e729aab59c37aa67a71d09f76dd2c7b2a214

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 1.20 (as in the example above) you'd only check for updates for that specific tag - that's the reason behind having the tags set in the first place compared to using :latest.

And if you're using :latest - then tags and versions are not taken into account at all.

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.

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.

@thomas-mc-work
Copy link
Contributor Author

thomas-mc-work commented Mar 9, 2024

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])

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants