podman-auto-update support for auto updates on base image changes for Containerfile/Dockerfile?

[fice-t]

Consider this Containerfile from the official Caddy docker description:

FROM caddy:<version>-builder AS builder

RUN xcaddy build \
    --with github.com/caddyserver/nginx-adapter \
    --with github.com/hairyhenderson/caddy-teapot-module@v0.0.3-0

FROM caddy:<version>

COPY --from=builder /usr/bin/caddy /usr/bin/caddy

My goal is to have a container, starting from an image built from a Containerfile like the above, that is auto updated via podman-auto-update whenever the base caddy:<version> or caddy:<version>-builder images are updated on the remote registry.

Using io.containers.autoupdate for podman run with registry or local doesn't work, since the service checks the local resulting image for updates instead of the base image(s). Perhaps I could create a separate systemd service/timer that does a podman build --pull newer <...> which updates the local image for podman-auto-update, but that seems to be duplicating a lot of what podman-auto-update does for containers based on remote images. It would be nice to have this update machinery tied up together in the Podman definitions for the image/container so podman-auto-update would handle everything.

Am I missing some functionality built into Podman? If not, would this be a reasonable feature request? I was imagining perhaps support for the AutoUpdate key for Build units that would rebuild the image when necessary and restart any derived containers (like AutoUpdate for Container units). Or perhaps a new value for io.containers.autoupdate (local-rebuild-if-newer) that acts like local but tries to rebuild with --pull newer on base image changes.

[M1cha]

The issue with this is that it only solves a very specific usecase. Ideally you'd also want to rebuild the image if whatever you install has been updated. In your case that would be nginx-adapter and caddy-teapot-module. In other cases these might be e.g. apt packages.

This means that the determining if an image needs to be rebuild is image specific. For my personal use I've solved this by writing a service which runs every night and runs has_updates script inside the images. But even that has limitations.