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

[FEATURE] Allow user to disable or silence valueFromEnvironmentNotice warnings #407

Closed
wconnorwalsh opened this issue Jun 15, 2023 · 8 comments · Fixed by #436
Closed

[FEATURE] Allow user to disable or silence valueFromEnvironmentNotice warnings #407

wconnorwalsh opened this issue Jun 15, 2023 · 8 comments · Fixed by #436
Labels
enhancement New feature or request

Comments

@wconnorwalsh
Copy link

wconnorwalsh commented Jun 15, 2023

Is your feature request related to a problem? Please describe.
When using environment variables to configure Doppler, the valueFromEnvironmentNotice CLI function writes a warning to stderr each time a Doppler command is executed. This behavior can be irritating, especially when executing doppler run dozens of times per day.

I understand that these messages were originally printed to stdout, but due to the "noisiness" of the output, they were later changed to stderr. I think that solved one issue while creating the same issue somewhere else. These messages are warnings, not output or errors.

Describe the solution you'd like
There are a couple of different approaches that would work:

  1. It would be helpful if users could disable or silence the valueFromEnvironmentNotice warnings, either by executing a config command and storing the preference, setting an environment variable, or warning once per session (or day) and requiring the user to agree on the CLI with y/n before continuing.
  2. Reduce the frequency of the warning output to once per session, or once per day
  3. Make these warnings opt-in. I'm not sure these warnings should really be on by default. I think I understand the use case – to alert the user that a "hidden" flag is overriding the CLI – but isn't almost everything about Doppler's config "hidden" from the user on the CLI? These special environment variables are a supported and documented way to configure Doppler, and any user who happens to have set them, should know that they are set. So perhaps they should be opt-in instead with a flag --verbose, --debug, or --enable-warnings?

Describe alternatives you've considered
I've tried wrapping the doppler CLI binary in a shell function that redirects all stderr output to /dev/null. This quickly became overly complicated and required additional logic to ensure "valid" stderr actually was emitted.

Additional context
This behavior creates other unintended consequences. This issue was raised in connection with a related issue with the Doppler VSCode extension (DopplerHQ/vscode#22). Allowing users to disable or silence these warning provides greater flexibility and usability for customers who prefer to use environment variables to configure Doppler.

@agilesteel
Copy link

agilesteel commented Jun 23, 2023

+1 for this.

We manage the version via nix and we have a lot of scripting around the doppler cli and now we see this warning dozens of times per day.

Please at least disable it in the next version until you found a better solution like @wconnorwalsh suggested.

@agilesteel
Copy link

Any updates on this?

@Piccirello
Copy link
Contributor

This is on our radar but we don't have any updates to share at this time.

@agilesteel
Copy link

Cool cool. If you like I could send a PR with that one line commented out until you can figure out a proper solution...

@Piccirello
Copy link
Contributor

This warning is important and we would prefer to keep it enabled in the general case. This behavior will be opt-out, rather than opt-in.

@nmanoogian
Copy link
Member

Thanks again for your feedback on this, @agilesteel and @wconnorwalsh! Please let us know if the doppler configure flags commands meet your needs here

@agilesteel
Copy link

Already tested. All good.

@wconnorwalsh
Copy link
Author

Looks great – thank you!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Development

Successfully merging a pull request may close this issue.

4 participants