[New Feature] Delayed updates

[Keonik1]

Hi, thanks for the script.

I'm just exploring auto-update tools for now, I was wondering if there is an option for delayed updates and in certain time slots.

Here's what I mean:

1. i have a running container
2. a developer releases a new version
3. a timer is started that waits that this container has not been deleted or replaced (hash changed for the new tag released) for N seconds/minutes/days.
4. If the container is "stable", then you can update to it, but the update itself should be scheduled and performed at a certain time, for example, from 02:00 to 06:00 in the morning.

[jansppenrade2]

Hi Keonik1,

Thank you for your message. Currently this is not implemented yet, but I think your idea makes a lot of sense. I hadn't thought of that before.

I just checked if the image tags on Docker Hub contain a timestamp, and indeed, the "last_updated" attribute seems to be relevant for this purpose.

I could add a new attribute in the config file where you could specify the minimum age (in seconds) that a new image should be before an update is made.

The time slot for the installation is essentially configured through a cron job. If the cron job is set to start the script at 02:00 AM, it will check for available updates. If an update is found, the "last_updated" attribute would be checked. If the image age is older than the configured number of seconds, it would be downloaded. Otherwise, the check would be done again during the next script execution.

What do you think? Would this be sufficient for your needs?

Example json from Docker Hub with an attribute "last_updated":

[...]
      "last_updated": "2024-05-14T20:02:01.789159Z",
      "last_updater": 1156886,
      "last_updater_username": "doijanky",
      "name": "29.0.0-fpm",
      "repository": 1142795,
      "full_size": 442095890,
      "v2": true,
      "tag_status": "active",
      "tag_last_pulled": "2024-05-20T16:10:38.07516Z",
      "tag_last_pushed": "2024-05-14T20:02:01.789159Z",
      "media_type": "application/vnd.docker.distribution.manifest.list.v2+json",
      "content_type": "image",
      "digest": "sha256:96299f0933835dae1c50f474d2e3d047d62886a9be0c0cb5a748d8d9af2517ac"
    }
  ]
}

[Keonik1]

@jansppenrade2

Yeah, I think that would be completely sufficient, at least that's roughly the behavior I was referring to.

If this is implemented, I would be very grateful!

But there is one more question: At what point in time will the update pre-script be executed?

• Before the initial check that there is a new version of the container
• After checking that there is a new container version and before checking the "last_updated" field.
• Or after all checks (I would like this option)

[jansppenrade2]

Hey @Keonik1,

Alright, let me work on it.

Regarding your question about pre-script execution: The pre-scripts are executed after all conditions for running the new container are met - so it's your third option.

[Keonik1]

@jansppenrade2 Thank you! I will wait for the realization.