keep the latest tag of the docker image up to date?

[rtheg]

Hi!

Im using Nominatim (as Docker Image) for a mapserver project, and Im quite fond of it.
However: Im trying to create an automatic update script which keeps all of my docker containers up to date, and for this I have to rely on the :latest-tag, and on authors to keep that tag up-to-date, since I know no better way to make sure the newest (stable) version of a docker container is used.
But I run into the issue that mediagis/nominatim is the only docker container we use, where the :latest-tag does not seem to be maintained properly.
It seems the (stable?) version of mediagis/nominatim is at 3.7, while the :latest-tag in the official docker repository was update last to 3.4.
So might I kindly ask you to keep the stable tag more up to date, maybe teach the mediagis-bot to properly update it, if a release is considered stable? It would help automatic updating a lot.

Regards,
Rico

[leonardehrenfried]

Well, you're probably aware of all the things that can go wrong by doing that (data loss, renaming or removal of options...)?

On the other hand, I wouldn't be opposed to a PR that automatically sets the latest tag. Would you like to contribute it?

[rtheg]

Well, you're probably aware of all the things that can go wrong by doing that (data loss, renaming or removal of options...)?

I know using the :latest-tag is somewhat shunned, because of the many things that can go wrong. But I think the "never use :latest"-attitude, you can often find, is a bit too general. I prefer to check if and how the author updates :latest and, if I trust that author, I think its ok to use that tag (with the necessary precautions). The authors I checked so far seem to properly use it for the latest stable version, with the exception of mediagis/nominatim.
And yes, I have backups and could restore the volume data if for some reason the data there wouldn't be compatible with the newer version of the docker file, or even worse, if it gets broken due to incompatibility with the new image version.

On the other hand, I wouldn't be opposed to a PR that automatically sets the latest tag. Would you like to contribute it?

Hmm. I dont know if I would have the technical know-how to do so, since it would include tinkering with the update bot and my insight in the whole update process is much too shallow. Wouldn't it suffice to label a release as "stable" somewhere and teach the bot that, if the "stable" label is set, it should not only upload that version to dockerhub but also update the :latest image there with that image?
Sounds like something someone who has experience with the mediagis update bot might add quite quickly, and then it boils down to not forgetting the label when the current stable version is updated. (I noticed how the installation-guide of mediagis/nominatim currently explicitly mentions :3.7 as tag in the install command. So I'd say that whenever that documentation is updated it would be a good time to also update the stable version tag.)

[leonardehrenfried]

I didn't mean to berate you and it seems that you know what the risks are.

All of our time is limited so you'll have to wait until someone else makes the change you requested.

If you do decide to contribute, the tagging logic happens here: https://github.com/mediagis/nominatim-docker/blob/master/.github/workflows/ci.yml

[rtheg]

I didn't mean to berate you and it seems that you know what the risks are.

Thank you. I know very well, that I know nothing, but I try to mitigate the risks and make good choices in at the best of my ability. Actualy: Sorry if my answer seemed too harsh. I did not feel berated, but I try to be detailed in my reasoning, so things I overlook might be pointed out.

_All of our time is limited so you'll have to wait until someone else makes the change you requested.

If you do decide to contribute, the tagging logic happens here: https://github.com/mediagis/nominatim-docker/blob/master/.github/workflows/ci.yml_

Hmm, thanks, Ill look at it and see if I can get my head around it.

[philipkozeny]

Here‘s the challenge: since we only provide the docker images, we depend on the upgrade paths provided by the Nominatim team. Looking at previous releases, most of the times a (manual) migration path was needed to keep the version running. In addition there can be breaking changes when we change docker base images (e.g. Postgres upgrades). Although there is a migration tool from Nominatim since 3.7, this is still something that we need to consider.

I would only like to support :latest tags if we also find a committed maintainer that builds automatic migration paths for upgrades (Nominatim & docker) and tests therefore.

[rtheg]

I see your point, if someone tries to keep a consistent nominatim-database up-to-date with the :latest - Image.
But I just realized myself: Actualy, In case of Nominatim, I don't even have persistent data I need to be careful of. (Just take my previous comment, about backups, as general rule I use for the other Docker Containers, where I actualy have volume data which could break). I combine the automatic update of the Docker Image with a download of current map data and a rebuild of the database anyways.
So in my case just updating :latest with the current stable image would suffice, even if postgres data isn't migrated properly, since my script rebuilds from scratch anyways.

I guess the main question then would be, how representative my use case is for the usual behaviour of the other users which use this Docker Image.