mirror of
https://github.com/spantaleev/matrix-docker-ansible-deploy.git
synced 2026-05-08 05:10:14 +03:00
Slavi Pantaleev
d830c88275
matrix-bot-draupnir and matrix-appservice-draupnir-for-all share the same upstream container image. When both are enabled and force-pull is on (e.g. when pinning to a rolling tag like `latest` or `main`), the second role to run during a single playbook invocation sees the image as already up-to-date locally because the first role just pulled it. The community.docker.docker_image module reports `changed: false` in that case, so the second role's restart_necessary stays false and the conditional restart logic skips it. Result: the first service picks up the new image on restart, while the second keeps running the old one. For other versions which don't get force-pulled (other than `latest`), systemd service files also get updated by the playbook and these updates done by each role properly flip the "requires restarting" variable regardless of pulling. So it's just force-pulling that causes the problem. Treating force-pull itself as a restart trigger sidesteps the lossy "did this specific pull task fetch new bytes" heuristic. The downside is that both Draupnir services now restart on every run when force-pull is enabled, even when the upstream image has not moved. That is a small amount of waste compared to silently running an outdated container. Localized to these two roles via a comment that documents the constraint, rather than applied playbook-wide, since this is the only known image-sharing pair and other roles do not need the extra restarts. Fixes https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/5186 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>