v1.1.0

Recreating a container is now reported once, as the container, instead of again as the processes that ran inside it — and install purge removes the data it says it removed.

Both were found while recording the README's demo with 1.0.0. On a day when two containers were recreated and one of them changed image, report printed seven lines. Five of them repeated those two changes through the process table: each container's containerd-shim with its new ID, the process inside uptime-kuma that its new image renamed, and the image's entrypoint with a different command line. This release prints the two replaced lines. The first report after upgrading compares against a snapshot 1.0 wrote, which still holds every container's processes. If a container was recreated between that snapshot and the upgrade, its old processes are reported gone that one time. Clearing up the demo machine then turned up the second problem. install purge filebrowser had said Completely removed and left filebrowser's database and settings in two Docker volumes, there and on the soak machine before it.

⚠️ Behavior changes

• report no longer compares the processes that belong to a container or to watch (#315). Recreating one container used to produce seven lines where two said anything. Each container's containerd-shim carries the container's ID, so every recreation read as a new process, and the processes inside the container came and went with it. The container line already says the container was recreated, with its image. A process is placed by walking its parents, which ps gives on Linux, macOS and busybox alike. The docker events helper watch start runs is left out too, so an upgrade that changes its arguments is no longer replaced: docker. The watch process itself is still compared. What report gives up is a command line changing inside a container that kept running. The first report after upgrading compares against a snapshot that still holds every container's process, and those are matched and left out of it as well, except for a container recreated between the two runs, whose old processes are reported gone that once
• install purge now removes the Docker volumes the app's containers used, and names them (#324). It said ✅ Completely removed (containers + data) and left filebrowser's database and settings behind. The image declares /config and /database as volumes that the compose file does not map, so Docker gave each container an anonymous volume, and compose down keeps those. Purge now runs down -v and lists each volume it removed. It says Completely removed only when Docker confirms every one is gone. A volume that still exists (external, or used by another container) is listed as kept under Removed, except:, and one Docker could not be asked about is listed as unchecked, never as removed. No catalogue app declares a named or external volume, so what it removes beyond the app directory is exactly these. install_purge over MCP and POST /api/install/{app}/purge already answered data_preserved: false, and now that is true. uninstall is unchanged and keeps them