[BUG] - CLI requires non-empty VULTR_API_KEY for "help [..]" and "version" subcommands
nifr opened this issue · 4 comments
Describe the bug
Any of the vultr-cli help [..]
subcommands and vultr-cli version
...
- throw the following error
- abort with exit code
1
... if VULTR_API_KEY
is unset or empty string.
Please export your VULTR API key as an environment variable or add `api-key` to your config file, eg:
export VULTR_API_KEY='<api_key_from_vultr_account>'
To Reproduce
- Run
vultr-cli version
- Run
vultr-cli help version
Expected behavior
The CLI outputs it's current version or help for the corresponding subcommand.
Vultr-cli v2.18.2
or
Display current version of Vultr-cli
Usage:
vultr-cli version [flags]
Flags:
-h, --help help for version
Global Flags:
--config string config file (default is $HOME/.vultr-cli.yaml) (default "/root/.vultr-cli.yaml")
Screenshots
Not required.
Desktop (please complete the following information where applicable:
- OS: any (tested
linux/amd64
andlinux/arm64
) - Version:
v2.18.2
(latest release as of2023-10-13
)
Additional context
Can be worked around as follows:
VULTR_API_KEY='nonemptystring' vultr-cli version
VULTR_API_KEY='nonemptystring' vultr-cli help version
@nifr Thanks for the report. This is something that has been on the todo list for a long time. I'll see about adding a patch for these commands at least.
@optik-aper just came back here and I was amazed by your crazy response time.
Thank you so much for the quick response and for looking into this.
I discovered another important sub-command (completion
) that fails if VULTR_API_KEY
is unset.
source <(vultr-cli completion bash)
Errors out (obviously) as follows:
bash: api-key: command not found
bash: Please: command not found
Note: This also reveals that the error/warning message goes to stdout instead of stderr. Intended?
Current workaround for bash
, zsh
, [..] for anyone who ends up here until this issue resolved:
if command -v vultr-cli >/dev/null 2>&1; then
source <(VULTR_API_KEY='workaround' vultr-cli completion "${SHELL##*/}")
fi
I appreciate the additional info! I have a working fix on this, but I need to re-organize some of the code to make sure auth-required commands warn the user. Hopefully I'll have some time this week to wrap that part up.
Note: This also reveals that the error/warning message goes to stdout instead of stderr. Intended?
I missed this in my first read, sorry. That is how it's currently intended/designed but could be changed. I'll have to think about whether that makes sense to change and try experiments.