What’s the feature?
Store the previous, known-working version of the container during an update and present that info to the user following the update.
Why is it useful?
When allowing automatic updates for many containers, I often find that the new update causes a bug, breaks a feature that I depended on, or changes the config in a way that breaks the app. To fix this, I need to scrub through my unused images (if they weren't already pruned) and find the version I know to work, pin the container to that version in Docker compose, then recreate the container and wait for an update that fixes the bug or gives me time to fix the container manually. The issue is it can be difficult to find what version of the container I was previously on and if unused images are automatically pruned, it can become a guess-and-check based off the last few versions of the container. By storing the previous, known-working version of the container during an update, I could just go to Tugtainer, copy that version, then pin it directly without having to search for it.
Any extra thoughts?
In the future, additional functionality could be added to "rollback" the container to the previous version with a single click of a button, pulling the known-good image and recreating the container. This would require then auto updates to be turned off until a new version of the container is found that is more up-to-date than the breaking version. This might also require a blacklist of known-bad container versions stored per-container to ensure Tugtainer doesn't just automatically update to a known-bad version.
It would also be helpful to store a version history list (perhaps for the last ~10 versions) so if you don't use a service for a while, it auto updates multiple times, and one of those updates breaks it, you can try each previous version until you find the known-good one. Perhaps even a checkbox that allows you to manually set which containers are known-good and known-bad, and store known-good container versions indefinitely to ensure there's always a version to roll back to.
What’s the feature?
Store the previous, known-working version of the container during an update and present that info to the user following the update.
Why is it useful?
When allowing automatic updates for many containers, I often find that the new update causes a bug, breaks a feature that I depended on, or changes the config in a way that breaks the app. To fix this, I need to scrub through my unused images (if they weren't already pruned) and find the version I know to work, pin the container to that version in Docker compose, then recreate the container and wait for an update that fixes the bug or gives me time to fix the container manually. The issue is it can be difficult to find what version of the container I was previously on and if unused images are automatically pruned, it can become a guess-and-check based off the last few versions of the container. By storing the previous, known-working version of the container during an update, I could just go to Tugtainer, copy that version, then pin it directly without having to search for it.
Any extra thoughts?
In the future, additional functionality could be added to "rollback" the container to the previous version with a single click of a button, pulling the known-good image and recreating the container. This would require then auto updates to be turned off until a new version of the container is found that is more up-to-date than the breaking version. This might also require a blacklist of known-bad container versions stored per-container to ensure Tugtainer doesn't just automatically update to a known-bad version.
It would also be helpful to store a version history list (perhaps for the last ~10 versions) so if you don't use a service for a while, it auto updates multiple times, and one of those updates breaks it, you can try each previous version until you find the known-good one. Perhaps even a checkbox that allows you to manually set which containers are known-good and known-bad, and store known-good container versions indefinitely to ensure there's always a version to roll back to.