Watchtower sub-commands

[piksel]

There are some requests for specialized behaviour of watchtower that is currently not possible to do due to how linearly watchtower operates. This is a catch-all issue for those cases, with the aim of adding some additional sub-commands to watchtower to allow users to use the different parts of watchtower as separate CLI tools, perhaps chaining them together with their own custom logic using pipes, á la the unix way. Sort of like a "build your own watchtower" kit!

Subcommand proposals

watchtower images <FILTERS> [<CONTAINER> <CONTAINER>...] ¹

Retrieves the image names for the specified container, using the same filter/context/label logic as the "main" command

watchtower check <IMAGE> [<IMAGE>]

Checks the supplied images for newer versions outputting only those image names

watchtower recreate <CONTAINER> [<CONTAINER>...]

Stops the old container, removes it and creates a new container with the latest version of the container image

Optional arguments:

• --with-enable-label=<true|false|none> Sets the com.centurylinklabs.watchtower.enable label to the supplied value, allowing it to be ignore/included in the regular runs

watchtower create <INSPECT-JSON-FILE | ->

Creates a container from a captured output of docker inspect

watchtower [dis|en]able <CONTAINER>

Recreates the container using the watchtower.enable=true/false label (alias to watchtower recreate --with-enable-label=)

watchtower notify

¹ CONTAINER means either a container name or a container ID.

[simskij]

watchtower notify

I am not sure whether I understand the use case for this command in particular. Without running an update cycle, there's not much to notify about.

watchtower recreate <CONTAINER> [<CONTAINER>...]

should be conditional to there actually being a newer image. --force could override this.

--with-enable-label=

I would argue that --with-monitor-only-label=, --with-lifecycle-*, et al would be good additions here as well.

watchtower create <INSPECT-JSON-FILE | ->

Now that compose has been rewritten in go, should we support something like --from-compose-file <COMPOSE-FILE> as well? bootstrapping all the containers with the necessary watchtower labels. I'm also thinking we should make this a docker-cli plugin just as compose. To be completely honest, converting watchtower itself into a (regular) docker plugin is something I find very tempting.

Some additional commands I'd like to see:

• watchtower generate-report
• watchtower config <debug-logs, interval, metrics, monitor-only> <value>

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[thomas-profitt]

Using these subcommands in a script is one way to implement https://github.com/containrrr/watchtower/issues/1401. It would still be good to make it more automatic or more declarative, if other approaches described there are feasible. But implementation of these subcommands would make it possible.