techsquidtv / uhs-cli Goto Github PK

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 <service> -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.

While the generated configuration files are accurate and built from our go structs, once written to YAML it appears we are unable to then unmarshal it back into the structs. This functionality is necessary for being able to edit individual section of config without rewriting the entire file.

I am a bit new to Go so I am not yet aware of the issue and will do more research on this soon, I needed to write it down first so I do not forget.