linode
Decode base64-encoded fields during output
Closes https://github.com/linode/linode-cli/issues/247
Related to https://github.com/linode/linode-api-docs/pull/468
The API returned kubeconfigs as a base64-encoded YAML string. The linked docs PR uses the appropriate JSON Schema fields to note the encoding and actual media type, and this CLI PR adds support for that information and handling it.
However, the output for linode-cli lke kubeconfig-view $CLUSTER_ID is
pretty terrible with this change. The token and certificate-authority-data
fields are very long, and cause wrapping in the terminal, which messes
up the entire output table. This can be corrected by using --text as
the output format, which, paired with --no-headers, produces a
nicely-formatted YAML file as output; the default behavior being ugly
isn't great in my opinion though.
This change isn't strictly necessary, as a user can run
linode-cli lke kubeconfig-view $CLUSTER_ID --text --no-headers | base64 -d
to see the same output today; however, having the default output be
useful would be a nice touch.
I see the following options here:
- Accept that the current output is fine and do not merge this PR
- Accept that this PR's output is ugly by default and merge it anyway
- Come up with a way to signal to the CLI that an operation should
default to
--text --no-headers-style output as part of this PR.
This change probably also represents a breaking change for the CLI, as an existing script that does the decoding as noted above would stop working with this change merged in.
Opinions appreciated; I will close/open/update this PR as relevant based on discussion here.
As much as I agree and hate the look of that output, I think keeping it the way it is currently is probably best. If nothing else it's consistent (albeit really ugly looking for this particular endpoint).
Perhaps adding some information about this in the Customizing Output section of the README file - specifically for cases of really long output - would be helpful and a sufficient solution?
I'm a bit late to this discussion, but I personally think it would be best to keep the output as base64 encoded to prevent breaking changes and to have a bit of a cleaner output.
@Dorthu Are you good with me closing out this PR?
