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.
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
commonarea (soon to be renamed toglobal), and aservicesarea. Thecommonarea 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.comAn init command gives an opportunity to generate a new
secrets.yamlconfig file from scratch as well as prompt a special configuration process for thecommonarea, 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.comConsiderations
Should the
initcommand attempt to validate and/or create paths selected in the configuration process?Example, if after running the
initcommand, a user configuresPlexwith a library location of/libraryand 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.yamlbe generated at this point as well? (thinking yes)generate
uhs generate -o values.yamlThis command is responsible for generating the default
values.yamlfile. This is a static file containing all of the default values for the chart. Users must have both avalues.yamland a customizedsecrets.yaml.Considerations
If
-ois not included, what should happen? Should the output be written tovalues.yamlby default? Or should output print tostdoutso the user could redirect it to a file (ex:uhs generate > values.yaml). Do we even need a-oflag?configure
uhs configure <service> -i secrets.yamlThe
configurecommand is used to modify the values in thesecrets.yamlfile for a particular service.-iis optional but will fail ifsecrets.yamlis not found in the current directory. Changes are written back to the same file.