[tmilnthorp]

As discussed on Discord: images are currently only built on dev pushes and tags, so a release image never gets base-OS security fixes after it ships. (Background: #2673.)

This adds a weekly schedule (Mondays 04:00 UTC) and a workflow_dispatch trigger to build-docker.yml. Each run rebuilds two images:

• dev, pushed as :dev.
• The latest GitHub release (from gh release view), checked out at its tag, with the wheel built from that tag using uv build. It is pushed with the same tags a release build produces (X.Y.Z + latest).

metadata-action now uses context: git, so tags come from the checked-out ref. On the existing workflow_run path that ref is still the default branch, so the current behaviour stays the same: same condition, same downloaded wheel, same tags, same job name.

Other cadences are a one-line change if you prefer one:

• Monthly: fewer republishes, but a longer window before fixes land.
• Weekly, but push only when the base image digest changed: avoids weekly Watchtower/Renovate updates when nothing changed. Happy to add this as a follow-up.

Release images only benefit once a release is built on the 3.23 base (the 4.5.13 tag's Dockerfile pins Alpine 3.21, which is end-of-life). The release-trigger issues I mentioned are fixed in a separate PR.

Checked with actionlint.

[tmilnthorp]

Thinking about this more, there's a trade-off you might want a say in before merging.

As written, the weekly job rebuilds from unchanged source and picks up whatever python:3.12-alpine3.23 points to that week, then pushes it straight to :dev and the release tags. That keeps images patched, but the published image changes with no review or test. If a base update ever broke something, latest would be replaced unseen.

Two other options:

1. Digest pin plus Dependabot, for dev. Pin the base as python:3.12-alpine3.23@sha256:… and add a docker entry to dependabot.yml (weekly). Each base update then arrives as a PR that runs Python CI, and you merge it like any other change. It's reviewed, tested and reproducible. The catch: released images are built from their tag's pinned Dockerfile, so they only get fixes when you cut a new release.
2. Keep the scheduled rebuild for the latest release, but smoke-test before pushing. Start the image, check appdaemon --version, and confirm it serves on 5050. A broken base fails the job instead of replacing latest.

My suggestion would be both: Dependabot PRs for dev, and a smoke-tested weekly rebuild for the latest release, since that's the only way shipped images get OS fixes between releases. But it depends how many PRs you're happy to review. If weekly Dependabot PRs sound like noise, the rebuild alone (plus the smoke test) does the job. Happy to update this PR whichever way you prefer.

[tmilnthorp]

I'd suggest closing this in favour of a PR-driven approach. #2686 now pins the base image by digest so Dependabot can open update PRs, and #2688 makes release tags publish their images. Base OS fixes then reach users through normal (patch) releases instead of tags being republished on a schedule. Every published image stays reviewed and CI-tested. Happy to close it if you agree. Sorry for the churn!