Update containers only if there has not been an update in last X days

[fede843]

Is your feature request related to a problem? Please describe.

Hello,

I was reading the documentation I and was hopping to find some feature to let me update the container's image only if it has been updated, and no update has happened in the last X days.

This is to prevent some rushed updates. Some projects are released without a proper testing maybe (or perhaps with the proper testing but still failing under certain conditions), and quickly after release, community gives feedback and they publish a quick minor update with the fix.

That would allow to be on the latest version, with some more "safety" feeling if you will.

Describe the solution you'd like

Have a label, say wait_N_days_before_update (or the name you like) where user can set the proper time when needed.

Describe alternatives you've considered

For some containers I had troubles in the past, I have disabled watchtower. From Portainer GUI is easy to detect if an update is available. Then I go check if it is recent or not, and depending on that I make the decision of updating or not.

Additional context

No response

[github-actions]

Hi there! 👋🏼 As you're new to this repo, we'd like to suggest that you read our code of conduct as well as our contribution guidelines. Thanks a bunch for opening your first issue! 🙏

[fede843]

Probably to implement this, it'll need to maintain certain containers info, i.e. last time updated by watchtower. That way it can compare.

[piksel]

In the manifest (image meta data) there is a Created field that shows when the tag was updated. The problem is of course that if you only check if that date is older than the target delay ago, you will end up with no updates if the tag is updated more often than that delay.
One way of solving it would be to check the docker daemons version of the image (the last pulled version) and skip pulling it if the wait_N_days_before_update label is present and the current container image doesn't match the docker daemons version.

It might be a bit too complex to include in the watchtower core though... Not sure.

[fede843]

OK, but the created field might not be totally accurate, depending on how we want to define this. Because a container recreation outside the watchtower flow would update it. It was thinking originally that watchtower to consider only the dates it creates a new container by itself. That is why I thought a kind of internal state should be kept.
I considered setting a label on the fly, but again it cannot be, because of this same reason. Any manual recreation would remove it.
And yes, of course that if the image update rate is faster the user defined value here, there will be no updates, but that is in the user side. No much you can do there, except a warning in documentation.

[piksel]

I meant the image's Created field. It shows when the image/tag was created and could be used to judge how long ago the image was last updated. And this is not something you can change, it's metadata from the repository/registry.

I see now that you wrote

and no update has happened in the last X days.

But that could still lead to an "untested" image being used. I don't see how waiting X days from when your local container was updated would help solving the problem?

[fede843]

OK, now I see, you mean that creation field, that is fine.

Let's explain how this would work:

Every day at update time, watchtower will grab the hash of any new image, with that date as timestamp, forcing to maintain a file with the first observation of this hash for futher checks to come, or better, use those images creation field you mentioned (can that be query remotely? probably not, so image can be download it then for this) without any need to keep a separate file. In any case, we compare the hash it against the current one in usage, to start with.
If not the same (an available update), we compare that remote image timestamp against the now - wait_N_days_before_update to decide if we update or not.
If the latest image has passed the defined thresold, the update is performed, otherwise it will wait one more day.
On the next day if image is the same, the time windows is naturally expanded 1 day longer, and eventually will get there. Or in case of a new image, that would be the one to start considering from there, with the proper updated timestamp, following the same logic.

A bit overworded, but to make it clearer. (hoefully)
This way we prevent those updates with buggy changes that are fixed in the next following 1 or 2 days scenario. For a new image to be updated we require at least X days being the latest.

[LiloBzH]

Hello

Same request for me. I don't use watchtower because it would require a delay for updates and avoid too rapid updates

Good idea, good request :-D

[pjdubya]

I came here looking for the same option to enable for at least some of my containers, probably all of them. I don't need to be on the bleeding edge the day it is released, but do love the automation that watchtower provides to keep containers up to date eventually. The reason I came looking for this today was, as @fede843 noted, I had a package update a few times now where there were some issues that were only caught after several people installed it, after which a new version was published to fix the issue. I would prefer to wait to install until there is stability on the latest, which as @fede843 described would be after the latest has been around for a few days. I don't think it's necessary to add very much complex logic here to do this though. It could simply do what it's doing today, i.e. check daily for the latest release, then if this delayed install flag is set, see if that latest release's Created tag is >= the # of days to delay, and if so, perform the update, otherwise wait. Given that this project is open source I'm happy to look into what it might take to implement if that helps.

[pjdubya]

I've made changes to support this. Working on validating it now and will push a PR once it looks to be working. Hopefully folks here are OK w/ the changes I made but was pretty straightforward -- will share the PR detail here in case anyone here has any input also.

[gingerbeardman]

Came here for this feature.

For a particular image, I want to eventually update after a week of no updates, rather than immediately.

@pjdubya did you file a PR?