You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 toglobal
), and aservices
area. Thecommon
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 thecommon
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 configuresPlex
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 avalues.yaml
and a customizedsecrets.yaml
.Considerations
If
-o
is not included, what should happen? Should the output be written tovalues.yaml
by default? Or should output print tostdout
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 thesecrets.yaml
file for a particular service.-i
is optional but will fail ifsecrets.yaml
is not found in the current directory. Changes are written back to the same file.The text was updated successfully, but these errors were encountered: