Some stacks not marked as updateavailable altnought there is a new image #324

New Issue

Closed

opened 2025-10-31 15:08:39 -05:00 by GiteaMirror · 26 comments

GiteaMirror commented 2025-10-31 15:08:39 -05:00

Owner

Copy Link

Originally created by @Twilek-de on GitHub (May 1, 2025).

With some stacks (it is always the same ones) Komodo does not fire an "Updateavailable" alert althought there is a new image available. In the container list this can be seen as the image only has a sha256 value

After manual redeployment the right image tag will show up again. So Komodo has already pulled the information that there is a new image but doesn´t fire the alert (I have activated the pull new images option for the stack and my alerter fires for stackupdates for other stacks correctly)

Originally created by @Twilek-de on GitHub (May 1, 2025). With some stacks (it is always the same ones) Komodo does not fire an "Updateavailable" alert althought there is a new image available. In the container list this can be seen as the image only has a sha256 value  After manual redeployment the right image tag will show up again. So Komodo has already pulled the information that there is a new image but doesn´t fire the alert (I have activated the pull new images option for the stack and my alerter fires for stackupdates for other stacks correctly) 

GiteaMirror added the bug1.19.2 labels 2025-10-31 15:08:39 -05:00

GiteaMirror closed this issue 2025-10-31 15:08:39 -05:00

GiteaMirror commented 2025-10-31 15:08:39 -05:00

Author

Owner

Copy Link

@gcebollero commented on GitHub (May 2, 2025):

Implement a new scheduled action than execute pull on the desired stacks. After the pull, the update notification is shown properly.

@gcebollero commented on GitHub (May 2, 2025): Implement a new scheduled action than execute pull on the desired stacks. After the pull, the update notification is shown properly.

GiteaMirror commented 2025-10-31 15:08:40 -05:00

Author

Owner

Copy Link

@Twilek-de commented on GitHub (May 2, 2025):

I am not sure that I understand what you are saying. I think the new image is already pulled. Otherwise Komodo/Docker wouldn´t know that the actual image does not have the "latest" tag anymore. What do you mean with implementing a scheduled action?

@Twilek-de commented on GitHub (May 2, 2025): I am not sure that I understand what you are saying. I think the new image is already pulled. Otherwise Komodo/Docker wouldn´t know that the actual image does not have the "latest" tag anymore. What do you mean with implementing a scheduled action?

GiteaMirror commented 2025-10-31 15:08:40 -05:00

Author

Owner

Copy Link

@kingp0dd commented on GitHub (May 5, 2025):

this started to happen after the last 2 updates. Currently, all my stacks are not showing the update icon in the Stack list even if there are image updates available.
I have to click the refresh button manually for it to show.

@kingp0dd commented on GitHub (May 5, 2025): this started to happen after the last 2 updates. Currently, all my stacks are not showing the update icon in the Stack list even if there are image updates available. I have to click the refresh button manually for it to show.

GiteaMirror commented 2025-10-31 15:08:40 -05:00

Author

Owner

Copy Link

@kingp0dd commented on GitHub (May 5, 2025):

this started to happen after the last 2 updates. Currently, all my stacks are not showing the update icon in the Stack list even if there are image updates available. I have to click the refresh button manually for it to show.

seems to have been fixed in the latest release

@kingp0dd commented on GitHub (May 5, 2025): > this started to happen after the last 2 updates. Currently, all my stacks are not showing the update icon in the Stack list even if there are image updates available. I have to click the refresh button manually for it to show. seems to have been fixed in the latest release

GiteaMirror commented 2025-10-31 15:08:41 -05:00

Author

Owner

Copy Link

@Twilek-de commented on GitHub (May 5, 2025):

this started to happen after the last 2 updates. Currently, all my stacks are not showing the update icon in the Stack list even if there are image updates available. I have to click the refresh button manually for it to show.

seems to have been fixed in the latest release

Nice, I will keep my eyes open wether available updates are shown.

@Twilek-de commented on GitHub (May 5, 2025): > > this started to happen after the last 2 updates. Currently, all my stacks are not showing the update icon in the Stack list even if there are image updates available. I have to click the refresh button manually for it to show. > > seems to have been fixed in the latest release Nice, I will keep my eyes open wether available updates are shown.

GiteaMirror commented 2025-10-31 15:08:41 -05:00

Author

Owner

Copy Link

@Twilek-de commented on GitHub (May 6, 2025):

I am still seeing updated stacks without notification

This triggered no Stackupdate Notification

@Twilek-de commented on GitHub (May 6, 2025): I am still seeing updated stacks without notification This triggered no Stackupdate Notification 

GiteaMirror commented 2025-10-31 15:08:42 -05:00

Author

Owner

Copy Link

@kingp0dd commented on GitHub (May 8, 2025):

Reporting back, I'm missing the update notification badges as well. I manually triggered one of my stacks, then suddenly the update badges of the other stacks started appearing. So I think it's not auto polling

@kingp0dd commented on GitHub (May 8, 2025): Reporting back, I'm missing the update notification badges as well. I manually triggered one of my stacks, then suddenly the update badges of the other stacks started appearing. So I think it's not auto polling

GiteaMirror commented 2025-10-31 15:08:42 -05:00

Author

Owner

Copy Link

@Twilek-de commented on GitHub (May 8, 2025):

It is always the same stacks which do not trigger the update. Others reliably do. I have not found the common denominator of the ones which don´t work. One that never triggers is the image of searxng with the latest tag on docker.io.

@Twilek-de commented on GitHub (May 8, 2025): It is always the same stacks which do not trigger the update. Others reliably do. I have not found the common denominator of the ones which don´t work. One that never triggers is the image of searxng with the latest tag on docker.io.

GiteaMirror commented 2025-10-31 15:08:42 -05:00

Author

Owner

Copy Link

@gcebollero commented on GitHub (May 13, 2025):

It is always the same stacks which do not trigger the update. Others reliably do. I have not found the common denominator of the ones which don´t work. One that never triggers is the image of searxng with the latest tag on docker.io.

I have been trying to determine why some stacks does not trigger the update... In my case, the update notification only works correctly if the container uses the 'latest' tag. If it is pinned to a particular version, the update notification never appears.
@Twilek-de can you check if you have the same behavior?

@gcebollero commented on GitHub (May 13, 2025): > It is always the same stacks which do not trigger the update. Others reliably do. I have not found the common denominator of the ones which don´t work. One that never triggers is the image of searxng with the latest tag on docker.io. I have been trying to determine why some stacks does not trigger the update... In my case, the update notification only works correctly if the container uses the 'latest' tag. If it is pinned to a particular version, the update notification never appears. @Twilek-de can you check if you have the same behavior?

GiteaMirror commented 2025-10-31 15:08:43 -05:00

Author

Owner

Copy Link

@Twilek-de commented on GitHub (May 13, 2025):

It is always the same stacks which do not trigger the update. Others reliably do. I have not found the common denominator of the ones which don´t work. One that never triggers is the image of searxng with the latest tag on docker.io.

I have been trying to determine why some stacks does not trigger the update... In my case, the update notification only works correctly if the container uses the 'latest' tag. If it is pinned to a particular version, the update notification never appears. @Twilek-de can you check if you have the same behavior?

I cannot confirm that. The SearXng container has the image with the "latest" tag, so that does not seem to be the deciding factor.

@Twilek-de commented on GitHub (May 13, 2025): > > It is always the same stacks which do not trigger the update. Others reliably do. I have not found the common denominator of the ones which don´t work. One that never triggers is the image of searxng with the latest tag on docker.io. > > I have been trying to determine why some stacks does not trigger the update... In my case, the update notification only works correctly if the container uses the 'latest' tag. If it is pinned to a particular version, the update notification never appears. [@Twilek-de](https://github.com/Twilek-de) can you check if you have the same behavior? I cannot confirm that. The SearXng container has the image with the "latest" tag, so that does not seem to be the deciding factor.

GiteaMirror commented 2025-10-31 15:08:43 -05:00

Author

Owner

Copy Link

@kingp0dd commented on GitHub (May 22, 2025):

I'm still getting the same issue for all my stacks.

@kingp0dd commented on GitHub (May 22, 2025): I'm still getting the same issue for all my stacks.

GiteaMirror commented 2025-10-31 15:08:43 -05:00

Author

Owner

Copy Link

@Twilek-de commented on GitHub (Jul 24, 2025):

I think I found the problem. All stacks that didn´t work had an image path starting with docker.io/.... I removed that and the updates are recognized now.

@Twilek-de commented on GitHub (Jul 24, 2025): I think I found the problem. All stacks that didn´t work had an image path starting with docker.io/.... I removed that and the updates are recognized now.

GiteaMirror commented 2025-10-31 15:08:43 -05:00

Author

Owner

Copy Link

@mbecker20 commented on GitHub (Jul 25, 2025):

@Twilek-de thanks for figuring out I was stumped, I wonder why docker.io/.. has issue while ghcr.io/.., gcr.io/.. and any other custom registry seems to work, will review

@mbecker20 commented on GitHub (Jul 25, 2025): @Twilek-de thanks for figuring out I was stumped, I wonder why docker.io/.. has issue while ghcr.io/.., gcr.io/.. and any other custom registry seems to work, will review

GiteaMirror commented 2025-10-31 15:08:44 -05:00

Author

Owner

Copy Link

@Twilek-de commented on GitHub (Jul 25, 2025):

docker.io also works, you just have to leave it out of the image path. Docker then automatically assumes it is docker hub and it works.

@Twilek-de commented on GitHub (Jul 25, 2025): docker.io also works, you just have to leave it out of the image path. Docker then automatically assumes it is docker hub and it works.

GiteaMirror commented 2025-10-31 15:08:44 -05:00

Author

Owner

Copy Link

@mbecker20 commented on GitHub (Jul 25, 2025):

Yes I am aware, I never use docker.io/.. just the image name, which is why I didn't notice the issue myself or recognize it from your description. I think this behavior of docker assuming docker.io is an edge case handled within docker code itself, possibly leading to auto update failure when it is specified, this is what I was going to review.

@mbecker20 commented on GitHub (Jul 25, 2025): Yes I am aware, I never use `docker.io/..` just the image name, which is why I didn't notice the issue myself or recognize it from your description. I think this behavior of docker assuming `docker.io` is an edge case handled within docker code itself, possibly leading to auto update failure when it is specified, this is what I was going to review.

GiteaMirror commented 2025-10-31 15:08:45 -05:00

Author

Owner

Copy Link

@mbecker20 commented on GitHub (Jul 25, 2025):

I think this is it, even if you pull docker.io/postgres:17, the image is silently renamed to just postgres. This doesn't happen for eg ghcr.io/... image, and leads to Komodo not seeing the newer image.

@mbecker20 commented on GitHub (Jul 25, 2025): <img width="679" height="241" alt="Image" src="https://github.com/user-attachments/assets/6cb1f26a-92c8-49ef-a856-6a47b59b610f" /> I think this is it, even if you pull `docker.io/postgres:17`, the image is silently renamed to just `postgres`. This doesn't happen for eg `ghcr.io/...` image, and leads to Komodo not seeing the newer image.

GiteaMirror commented 2025-10-31 15:08:45 -05:00

Author

Owner

Copy Link

@Twilek-de commented on GitHub (Jul 25, 2025):

I have just removed the docker.io from all my stacks so for me the problem is gone. But I think it would be good if komodo could handle it, as a lot of ready made copy and past docker compose files from the web use it.

@Twilek-de commented on GitHub (Jul 25, 2025): I have just removed the docker.io from all my stacks so for me the problem is gone. But I think it would be good if komodo could handle it, as a lot of ready made copy and past docker compose files from the web use it.

GiteaMirror commented 2025-10-31 15:08:45 -05:00

Author

Owner

Copy Link

@teedoff087 commented on GitHub (Aug 26, 2025):

My stacks were updating automatically a couple of releases ago, but something in the last 2 updates caused this to stop working. I'm going to implement a Procedure to update them weekly, but ideally I would like this to work on its own like it was before.

@teedoff087 commented on GitHub (Aug 26, 2025): My stacks were updating automatically a couple of releases ago, but something in the last 2 updates caused this to stop working. I'm going to implement a Procedure to update them weekly, but ideally I would like this to work on its own like it was before.

GiteaMirror commented 2025-10-31 15:08:45 -05:00

Author

Owner

Copy Link

@mbecker20 commented on GitHub (Aug 26, 2025):

@teedoff087 see https://komo.do/docs/resources/auto-update, it was mentioned in release notes with 🚨. But it's easy to set up and gives you a lot more easy control when to run global auto update. I also move to once a week updates and very happy with this.

@mbecker20 commented on GitHub (Aug 26, 2025): @teedoff087 see https://komo.do/docs/resources/auto-update, it was mentioned in release notes with 🚨. But it's easy to set up and gives you a lot more easy control when to run global auto update. I also move to once a week updates and very happy with this.

GiteaMirror commented 2025-10-31 15:08:46 -05:00

Author

Owner

Copy Link

@teedoff087 commented on GitHub (Aug 26, 2025):

@teedoff087 see https://komo.do/docs/resources/auto-update, it was mentioned in release notes with 🚨. But it's easy to set up and gives you a lot more easy control when to run global auto update. I also move to once a week updates and very happy with this.

Yeah, I've got it set up now and everything is working fine. I was just alarmed the updates stopped working. I should have read the release notes in detail, but it's hard to keep up with how fast the updates keep coming. Thank you!

@teedoff087 commented on GitHub (Aug 26, 2025): > [@teedoff087](https://github.com/teedoff087) see https://komo.do/docs/resources/auto-update, it was mentioned in release notes with 🚨. But it's easy to set up and gives you a lot more easy control when to run global auto update. I also move to once a week updates and very happy with this. Yeah, I've got it set up now and everything is working fine. I was just alarmed the updates stopped working. I should have read the release notes in detail, but it's hard to keep up with how fast the updates keep coming. Thank you!

GiteaMirror commented 2025-10-31 15:08:47 -05:00

Author

Owner

Copy Link

@mbecker20 commented on GitHub (Aug 27, 2025):

Understood. I put the most important info like this at the very top of release notes with 🚨, if you glance at one part just check this.

@mbecker20 commented on GitHub (Aug 27, 2025): Understood. I put the most important info like this at the very top of release notes with 🚨, if you glance at one part just check this.

GiteaMirror commented 2025-10-31 15:08:47 -05:00

Author

Owner

Copy Link

@mbecker20 commented on GitHub (Aug 28, 2025):

The bug here is when user use images beginning with docker.io. When the image is pulled, Docker itself silently removes docker.io/ from the image tag (docker.io/postgres:17 -> postgres:17), opening up edge case for this specific registry causing failure to recognize image update. It will work for users immediately if they remove docker.io/ from images. Leaving this open for Komodo to close the edge case.

@mbecker20 commented on GitHub (Aug 28, 2025): The bug here is when user use images beginning with `docker.io`. When the image is pulled, Docker itself silently removes `docker.io/` from the image tag (`docker.io/postgres:17 -> postgres:17`), opening up edge case for this specific registry causing failure to recognize image update. It will work for users immediately if they remove `docker.io/` from images. Leaving this open for Komodo to close the edge case.

GiteaMirror commented 2025-10-31 15:08:47 -05:00

Author

Owner

Copy Link

@kingp0dd commented on GitHub (Aug 29, 2025):

The bug here is when user use images beginning with docker.io. When the image is pulled, Docker itself silently removes docker.io/ from the image tag (docker.io/postgres:17 -> postgres:17), opening up edge case for this specific registry causing failure to recognize image update. It will work for users immediately if they remove docker.io/ from images. Leaving this open for Komodo to close the edge case.

I have compose that doesn't use that format but still have no update indicators. This happened only after updating to the 19.1

Are there logs i can look at to confirm or give more details about this?

@kingp0dd commented on GitHub (Aug 29, 2025): > The bug here is when user use images beginning with `docker.io`. When the image is pulled, Docker itself silently removes `docker.io/` from the image tag (`docker.io/postgres:17 -> postgres:17`), opening up edge case for this specific registry causing failure to recognize image update. It will work for users immediately if they remove `docker.io/` from images. Leaving this open for Komodo to close the edge case. I have compose that doesn't use that format but still have no update indicators. This happened only after updating to the 19.1 Are there logs i can look at to confirm or give more details about this?

GiteaMirror commented 2025-10-31 15:08:48 -05:00

Author

Owner

Copy Link

@mbecker20 commented on GitHub (Aug 29, 2025):

@kingp0dd confirm you scheduled GlobalAutoUpdate as mentioned here https://komo.do/docs/resources/auto-update

@mbecker20 commented on GitHub (Aug 29, 2025): @kingp0dd confirm you scheduled GlobalAutoUpdate as mentioned here https://komo.do/docs/resources/auto-update

GiteaMirror commented 2025-10-31 15:08:48 -05:00

Author

Owner

Copy Link

@kingp0dd commented on GitHub (Aug 29, 2025):

I'm sorry my bad. I missed the word new in the release notes. It's only
automatically installed on new 1.19

On Sat, Aug 30, 2025, 5:44 AM Maxwell Becker @.***>
wrote:

mbecker20 left a comment (moghtech/komodo#468)
https://github.com/moghtech/komodo/issues/468#issuecomment-3238351869

@kingp0dd https://github.com/kingp0dd confirm you scheduled
GlobalAutoUpdate as mentioned here
https://komo.do/docs/resources/auto-update

—
Reply to this email directly, view it on GitHub
https://github.com/moghtech/komodo/issues/468#issuecomment-3238351869,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACGD6KSO2J36Z6BJSUS3ODT3QDCSDAVCNFSM6AAAAAB4HQQHTOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTEMZYGM2TCOBWHE
.
You are receiving this because you were mentioned.Message ID:
@.***>

@kingp0dd commented on GitHub (Aug 29, 2025): I'm sorry my bad. I missed the word new in the release notes. It's only automatically installed on new 1.19 On Sat, Aug 30, 2025, 5:44 AM Maxwell Becker ***@***.***> wrote: > *mbecker20* left a comment (moghtech/komodo#468) > <https://github.com/moghtech/komodo/issues/468#issuecomment-3238351869> > > @kingp0dd <https://github.com/kingp0dd> confirm you scheduled > GlobalAutoUpdate as mentioned here > https://komo.do/docs/resources/auto-update > > — > Reply to this email directly, view it on GitHub > <https://github.com/moghtech/komodo/issues/468#issuecomment-3238351869>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ACGD6KSO2J36Z6BJSUS3ODT3QDCSDAVCNFSM6AAAAAB4HQQHTOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTEMZYGM2TCOBWHE> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >

GiteaMirror commented 2025-10-31 15:08:48 -05:00

Author

Owner

Copy Link

@kingp0dd commented on GitHub (Sep 17, 2025):

sorry to reopen this. but i use the new method of Procedure to scan for updates:

[[procedure]]
name = "global update"
config.webhook_enabled = false
config.schedule_format = "Cron"
config.schedule = "0 0 5 * * *"
config.schedule_timezone = "Asia/Shanghai"

[[procedure.config.stage]]
name = "Stage 1"
enabled = true
executions = [
  { execution.type = "GlobalAutoUpdate", execution.params = {}, enabled = true }
]

the procedure runs successfully as scheduled, but the Update icons are not showing again in Stack list:

which logs to check to confirm the issue?

@kingp0dd commented on GitHub (Sep 17, 2025): sorry to reopen this. but i use the new method of Procedure to scan for updates: ``` [[procedure]] name = "global update" config.webhook_enabled = false config.schedule_format = "Cron" config.schedule = "0 0 5 * * *" config.schedule_timezone = "Asia/Shanghai" [[procedure.config.stage]] name = "Stage 1" enabled = true executions = [ { execution.type = "GlobalAutoUpdate", execution.params = {}, enabled = true } ] ``` the procedure runs successfully as scheduled, but the Update icons are not showing again in Stack list: <img width="768" height="690" alt="Image" src="https://github.com/user-attachments/assets/87719f52-4526-498b-93d4-b78faddab0c2" /> <img width="585" height="910" alt="Image" src="https://github.com/user-attachments/assets/af256403-fac5-4c1c-a85b-121be64c5412" /> which logs to check to confirm the issue?

GiteaMirror referenced this issue 2025-10-31 15:20:46 -05:00

[PR #566] [MERGED] 1.18.1 #749

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

2.0.0

legacy-v1-frontend

copilot/secure-local-authentication

gh-pages-docs

v0

legacy

v2.0.0-dev-124

v2.0.0-dev-123

v2.0.0-dev-120

v2.0.0-dev-118

v2.0.0-dev-114

v2.0.0-dev-112

v2.0.0-dev-111

v2.0.0-dev-102

v2.0.0-dev-98

v2.0.0-dev-90

v2.0.0-dev-86

v2.0.0-dev-72

v2.0.0-dev-59

v2.0.0-dev-53

v2.0.0-dev-50

v2.0.0-dev-36

v1.19.5

v2.0.0-dev-35

v1.19.4

v1.19.3

v1.19.2

v1.19.1

v1.19.1-dev-14

v1.19.0

v1.19.0-dev-9

v1.18.4

1.18.5-dev-5

v1.18.3

v1.18.2

v1.18.1

v1.18.0

v1.17.5

v1.17.4

v1.17.3

v1.17.4-dev-1

v1.17.2

v1.17.2-dev-1

v1.17.1

v1.17.0

v1.17.0-dev-7

v1.17.0-dev-4

v1.17.0-dev-3

v1.17.0-dev-5

v1.17.0-dev-6

v1.17.0-dev-2

v1.17.0-dev-1

v1.16.12

v1.16.11

v1.16.10

v1.16.9

v1.16.8

v1.16.7

v1.16.6

v1.16.5

v1.16.4

v1.16.3

v1.16.2

v1.16.1

v1.16.0

v1.15.12

v1.15.11

v1.15.10

v1.15.9

v1.15.8

v1.15.7

v1.15.6

v1.15.5

v1.15.4

v1.15.3

v1.15.2

v1.15.1

v1.15.0

v1.14.2

v1.14.1

v1.14.0

v1.14.0-rc1

v1.13.4

v1.13.3

v1.13.2

v1.13.1

v1.13.0

v1.12.0

v1.11.0

v1.10.0

v1.9.0

v1.8.0

v1.7.3

v1.7.0

v1.6.0

v1.5.0

v1.4.0

v1.2.0

v1.1.0

v1.0.0

v0.3.4

v0.3.3

v0.3.2

v0.3.0

v0.2.14

v0.2.13

v0.2.12

v0.2.11

v0.2.10

v0.2.9

v0.2.7

v0.2.6

v0.2.5

v0.2.4

v0.2.1

v0.2.0

v0.1.17

v0.1.16

v0.1.15

v0.1.11

v0.1.10

v0.1.9

Labels

Clear labels

1.19.0

1.19.1

1.19.2

1.19.3

1.19.4

bug

documentation

done

enhancement

help wanted

info

pull-request

Mirrored from GitHub Pull Request

question

security

seen 👀

setup

thinking 🤔

ui

No Label 1.19.2 bug

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

GiteaMirror ninjasurge

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/komodo#324