Adds a TPI_HOSTNAME, TPI_USERNAME, TPI_PASSWORD and TPI_OUTPUT_JSON as fallbacks for the --host, --user, --password, and --json global arguments
$ tpi --help
Official Turing-Pi2 CLI tool
Usage: tpi [OPTIONS] [COMMAND]
[..snip..]
Options:
--host <HOST> Specify the Turing-pi host to connect to. Note: IPv6 addresses must be wrapped in square brackets e.g. `[::1]`
[env: TPI_HOSTNAME=] [default: turingpi.local]
--port <PORT> Specify a custom port to connect to [env: TPI_PORT=]
--user <USER> Specify a user name to log in as. If unused, an interactive prompt will ask for credentials unless a cached token
file is present [env: TPI_USERNAME=]
--password <PASS> Same as `--username` [env: TPI_PASSWORD=]
--json Print results formatted as JSON [env: TPI_OUTPUT_JSON=]
(clap's help message gen will also include the values if they are found in the environment;
of note this can—under less than clear conditions (something termcap-y?)—cause(?) the help to get re-flowed. If anything, its more legible that way - but in case there's anything text-parsing this output somewhere [in tests or automation] seems worth mentioning)
[why? b/c I am connecting to my cluster over tailscale (after these modifications to the BMC firmware to make that possible) and getting tired of typing --host turingpi.XXXX.ts.net ;
but also broadly I believe these should be options]
It is plausible that it is preferable to match the argument names, but I leaned in the direction of things that are slightly more self-documenting in the context of a .bashrc or .zshenv
I have mixed feelings about encouraging mediocre security practices vis-a-vis putting a secret in an environment variable (and probably directly in a file);
The easiest alternative there would be to have a TPI_PASSWORD_CMD that one could set to e.g. op item get "Turing Pi BMC root" --field label=password (that or go harder on e.g. TLS client certs, etc.)
Adds a
TPI_HOSTNAME,TPI_USERNAME,TPI_PASSWORDandTPI_OUTPUT_JSONas fallbacks for the--host,--user,--password, and--jsonglobal arguments(clap's help message gen will also include the values if they are found in the environment;
of note this can—under less than clear conditions (something termcap-y?)—cause(?) the help to get re-flowed. If anything, its more legible that way - but in case there's anything text-parsing this output somewhere [in tests or automation] seems worth mentioning)
[why? b/c I am connecting to my cluster over tailscale (after these modifications to the BMC firmware to make that possible) and getting tired of typing
--host turingpi.XXXX.ts.net;but also broadly I believe these should be options]
It is plausible that it is preferable to match the argument names, but I leaned in the direction of things that are slightly more self-documenting in the context of a
.bashrcor.zshenvI have mixed feelings about encouraging mediocre security practices vis-a-vis putting a secret in an environment variable (and probably directly in a file);
The easiest alternative there would be to have a TPI_PASSWORD_CMD that one could set to e.g.
op item get "Turing Pi BMC root" --field label=password(that or go harder on e.g. TLS client certs, etc.)