Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposing Redesign and UX Enhancement for CLI Commands #17

Open
KyleTryon opened this issue Jun 22, 2023 · 0 comments
Open

Proposing Redesign and UX Enhancement for CLI Commands #17

KyleTryon opened this issue Jun 22, 2023 · 0 comments

Comments

@KyleTryon
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant