Add a --silent flag to the read / run command about secrethub-cli HOT 15 CLOSED

My vote goes to --ignore-missing-secrets ;)

from secrethub-cli.

This is included in v0.25.0.

from secrethub-cli.

It's nice to be able to not block the app from running, but I'd expect a --silent flag to just suppress the output, not to alter the error handling flow.

Maybe an --allow-empty flag would make more sense. It would still give an error if something else is going wrong, but would allow for empty / non-existing values.

from secrethub-cli.

Hi @mackenbach ,

I am building a terraform docker image that has an entrypoint shell script which uses SecretHub to inject some secrets.

One of those secret is the kubeconfig yaml file to talk to a k8s cluster but this secret does not exist until the k8s cluster has been terraformed. I dont want to emit any error when I try to inject this secret at boot time of the container.

I also trying to standardize some approach around that image so it can be used in environment where openstack is being used but this is entirely optional and again, I don't want to emit any error if the secret simply doesn't exist.

I am pretty sure there are a lot more scenarios where this flag would be useful. Also take into consideration that there is no way to test if a given secret exists or not. At the same time, it's not so desirable to offer such command as it would require 2 round trips to check and get a secret. It's a lot simpler to simply get the secret and test if it's empty / does not exist, assuming the cli does not prevent you from doing it which is the case at the moment.

This is more or less the same reason why curl for example is offering such flag as well.

from secrethub-cli.

Ya actually this is a better option @florisvdg and it addresses specifically the problem at hand without creating some loopholes.

from secrethub-cli.

Hi Christian, thanks for submitting the feature request! Definitely an interesting use case. Could you give us a bit more background as to why you'd like the CLI to ignore missing secrets? What are you trying to achieve that the secret_not_found error is blocking you from now?

from secrethub-cli.

Ah great, that makes total sense! We should be specific about which types of errors we ignore though, as e.g. syntax errors should still be caught and outputted IMO.

The help text could look something like this:

-s, --silent

   Silent or quiet mode. Don't show error messages and ignore non existing or empty secrets. 

I'm thinking should not erroring actually be the default? Then the run command is always non-blocking by default and you're guaranteed your process starts, except maybe not configured the way you'd expect it to be. @florisvdg what's your opinion?

from secrethub-cli.

Just occurred to me that -allow-empty is not ideal either because it's not that the value is empty, the key does not even exit.

from secrethub-cli.

Yes, but the idea would be that with the allow-empty flag set, a key not existing would result in an empty environment variable. In other words: the variable is optional, so whether the secret is not found or the value is just empty: it's okay, because empty values are allowed (with the flag set).

from secrethub-cli.

I understand how you are looking at this but it might not be so clear for the user without any context or a description of the flag. Just genuinely wondering if there is maybe a better name that would convey a bit more the intention.

from secrethub-cli.

Alternatives I can think of: --optional or --lenient.

from secrethub-cli.

Nice work guys, all that's left is to come up with a simple auto-documenting name. A few options I can think of are:

• --ignore-empty-secrets
• --ignore-non-existing-secrets
• --ignore-missing-secrets
• --allow-empty-values
• --allow-missing-values

from secrethub-cli.

any chance to ship this tiny request soon ? Thanks in advance

from secrethub-cli.

Hi @tlvenn, yes we're picking it up next sprint. Many people are returning from holidays next week. We'll keep you posted 😊

from secrethub-cli.

Great suggestion! I'll pick this up

from secrethub-cli.