Refactor CLI commands

[srueg]

Context

The commodore clean command removes the entire inventory and all components. Changes which are not checked into git will be lost. On a regular catalog compile (if not --local mode), the clean command is run first.

The safeguard should interactively ask if changes should really be dropped in case of a dirty workspace. A --force flag could be implemented to drop changes without asking first (for example in a CI/CD or test context).

[akosma]

This is a huge usability issue. A tool should never, under any circumstances, delete the work created by a user without (at the very least) getting a warning first. This behaviour is not only misleading, it can be counterproductive to a strategy directed towards driving others to use this tool.

My suggestion:

• The compile command never deletes anything, under any circumstances.
• Instead, a set of flags (like --clean or --delete or --force) explicitly does this; a warning is given unless --force is used. Even better, a separate command (see below)
• If the current state is incorrect for a compile command, this command should provide the user with the required contextual information and/or workarounds (for example, "use the --clean flag to start over") so that the user gets the work done.
• Add a separate set of commodore commands, such as the aforementioned clean (not a flag to another command, but rather a separate command: commodore clean) and also commodore push so that certain behaviours are explicit and coherent with a simple(r) mental model.

Given the heavy use of git in this project, using common git idioms (such as commit being different than push being different to checkout -- . to clean all changes) would help a lot.

[srueg]

I like the idea of this. Also, there already is a catalog clean command. I'd propose the following command structure: "Working dirs" means the following directories: inventory/*, dependencies/* and catalog.

• commodore catalog compile <cluster-id>
  • Compiles the catalog (without push)
  • If any working dir has a "dirty" state, ask what to do
  • Optional -f,--force to skip asking and remove all local changes
  • Optional -l,--local to skip asking and keep local changes
• commodore catalog push <cluster-id>
  • Compiles and pushes the catalog
  • Optional -i,--interactive flag to show changes and ask to push Y/n
  • If any working dir has a "dirty" state, ask what to do
  • Optional -f,--force to remove all local changes without asking
  • Not sure if we should implement the --local option here?
• commodore catalog fetch <cluster-id>
  • Fetches all working dirs
  • Optional -f,--force to skip asking and remove all local changes
  • Optional -l,--local to skip asking and keep local changes
• commodore catalog clean
  • Cleans all working dirs
• commodore catalog list/ls
  • Lists all catalogs (clusters) of this Lieutenant cluster

[simu]

How to handle more selective fetching in combination with local mode also came up in discussions regarding #160

The result of this discussion is that the following commands might be helpful to make the operation of Commodore more modular

• commodore inventory fetch CLUSTER_ID
  • Fetches only the inventory for the specified cluster
• commodore component fetch COMPONENT_NAME
  • Fetches only the specified component, taking into account any relevant configuration in inventory/ (commodore.yml, component_versions), if it exists.