After #16 resolves the ability to modify existing configuration files, I want to revisit the usage of the CLI and improve the UX.

Config File Anatomy

A config file is made up of two sections, a common area (soon to be renamed to global), and a services area. The common area is currently not modifiable with the CLI but still contains information that will need to be configured on the first generation of a config.

Suggested Commands

init

uhs init . -n example.com

An init command gives an opportunity to generate a new secrets.yaml config file from scratch as well as prompt a special configuration process for the common area, which is currently not generated.

In the future, we could potentially support templates for init to assist in quick setup, something like:
uhs init -t arr-template -n example.com

Considerations

Should the init command attempt to validate and/or create paths selected in the configuration process?
Example, if after running the init command, a user configures Plex with a library location of /library and it does not exist, should it be created after the setup? Should it be created when it is configured? Should it only present a warning?

Should the default values.yaml be generated at this point as well? (thinking yes)

generate

uhs generate -o values.yaml

This command is responsible for generating the default values.yaml file. This is a static file containing all of the default values for the chart. Users must have both a values.yaml and a customized secrets.yaml.

Considerations

If -o is not included, what should happen? Should the output be written to values.yaml by default? Or should output print to stdout so the user could redirect it to a file (ex: uhs generate > values.yaml). Do we even need a -o flag?

configure

uhs configure -i secrets.yaml

The configure command is used to modify the values in the secrets.yaml file for a particular service. -i is optional but will fail if secrets.yaml is not found in the current directory. Changes are written back to the same file.