You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This works well, but unfortunately results in all of the secrets being printed to the terminal whenever we run garden deploy (or garden run render-vals). We could avoid this by writing the secrets to a file, but we'd rather avoid having them all saved to disk as that opens up more opportunities for something to go wrong.
What should the user be able to do?
Configure a run action such that stdout and stderr are not printed to the terminal or shown in the Garden dashboard.
Why do they want to do this? What problem does it solve?
It avoids having secret output shown on their screen.
Suggested Implementation(s)
Originally I was thinking that we could add two configuration options: redirect_stdout and redirect_stderr. Then to stdout it you could set redirect_stdout to /dev/null. Unfortunately that would probably prevent actions.run.<name>.outputs.log from working correctly, so maybe a better approach would be to avoid generalizing this feature, and just add boolean toggles: hide_stdout and hide_stderr. They'd be false by default, which would be the current behaviour. When true, the output to the respective stream would still be available via actions.run.<name>.outputs.log, but it would not be printed to the terminal.
How important is this feature for you/your team?
🌹 It’s a nice to have, but nice things are nice 🙂
The text was updated successfully, but these errors were encountered:
Thank you @WillDaSilva for sharing this! Great feature request.
There's a problem with not printing the log output to the screen, or sending it to Garden cloud: what happens in case of an error? Then we need to print something to the screen, and it still might contain secrets.
There's another open feature request for marking certain values as sensitive, and filtering them in the log output: #5666
@WillDaSilva would you say this feature request is a duplicate of #5666 or would you still expect to have hide_stdout and hide_stderr toggles even though they'd be essentially ignored in case of an error?
@stefreak#5666 would satisfy my use case, but I can still imagine others may want the feature I described in this issue.
One thing I can imagine is if the output is very long, and printing it both takes a long time, and hides everything above.
I'll leave it up to your discretion whether we should close this and wait for someone else to make a request for this feature for reasons other than hiding secrets, or whether we should just leave this issue open.
Feature Request
Background / Motivation
Currently I have a run action called
render-vals
that fetches secrets that'll be used during a Helm deploy action like so:This works well, but unfortunately results in all of the secrets being printed to the terminal whenever we run
garden deploy
(orgarden run render-vals
). We could avoid this by writing the secrets to a file, but we'd rather avoid having them all saved to disk as that opens up more opportunities for something to go wrong.What should the user be able to do?
Configure a run action such that stdout and stderr are not printed to the terminal or shown in the Garden dashboard.
Why do they want to do this? What problem does it solve?
It avoids having secret output shown on their screen.
Suggested Implementation(s)
Originally I was thinking that we could add two configuration options:
redirect_stdout
andredirect_stderr
. Then to stdout it you could setredirect_stdout
to/dev/null
. Unfortunately that would probably preventactions.run.<name>.outputs.log
from working correctly, so maybe a better approach would be to avoid generalizing this feature, and just add boolean toggles:hide_stdout
andhide_stderr
. They'd be false by default, which would be the current behaviour. When true, the output to the respective stream would still be available viaactions.run.<name>.outputs.log
, but it would not be printed to the terminal.How important is this feature for you/your team?
🌹 It’s a nice to have, but nice things are nice 🙂
The text was updated successfully, but these errors were encountered: