-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Change configuration verbs for getting and setting values #563
Conversation
I'm worried that having I didn't understand the change from |
Sure. So
(Note that in the above example, I could have passed
We actually this feature ourselves in some scripts: https://github.com/pulumi/pulumi-service/blob/master/scripts/describe-stack.sh#L27 So the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. One suggestion:
I'm worried that having --secret not be the default will cause people to check in secrets. Is it too verbose to add a log message like "Added key {key} with value {value} as plaintext"?
Happy to do that, @joeduffy what do you think? Do you think this would get annoying after a bit? I definitely thing it would help train people to do the right thing. Do you think we'd want some sort of message for the |
@ellismg Good point. To be consistent, perhaps |
Thanks, @lindydonna I added another commit (and used the word "set" instead of "added" in the message, since it matches the verb and also you can use |
I tend not to love "simple" commands printing messages upon success, as the general UNIX philosophy is "no output means success." But it's fine to violate this in specific places with real use cases, and this certainly seems like a fine one (security). Note that it may be interesting eventually to run something like this: https://github.com/awslabs/git-secrets. The idea would be we could reject attempts to add a secret-like value
I realize it may be a bridge too far for now, but things like this can really improve our appeal to Enterprise developers, and is keeping with our theme of falling into the pit of success. Secret management is one of those areas that people just don't get right. It's not logical, but if this somehow just got added without me looking, I'd be a happy dude :-) |
Matt, how do I list all config values in the current stack? TBH, I really liked the old model of just saying |
Does this also change the default for |
No, it doesn't work like that. You write
No, I had forgotten about that issue (since I think it was in my slack scrollback vs an issue) but I can change that. Do you want to keep the version without the --save to be stack specific (as is the behavior now and how |
Curious what others think ... the way I wrote it is the way I'd prefer ... ( I also think "show me the current config" is going to be a very common "show me stuff without making me think" operation (e.g., something's going wrong, dump the config). Making that easy to type and making that the thing people default to typing seems like a good idea.
Right, but we don't apply it to every stack by default. I'm just saying
Unfortunately, because |
Based on the above discussion, I change things slightly. The text of the commit message is an accurate reflection of the state of the world:
I did not do the thing @joeduffy mentioned about having |
LGTM 👍 |
A handful of UX improvments for config: - `pulumi config ls` has been removed. Now, `pulumi config` with no arguments prints the table of configuration values for a stack and a new command `pulumi config get <key>` prints the value for a single configuration key (useful for scripting). - `pulumi config text` and `pulumi config secret` have been merged into a single command `pulumi config set`. The flag `--secret` can be used to encrypt the value we store (like `pulumi config secret` used to do). - To make it obvious that setting a value with `pulumi config set` is in plan text, we now echo a message back to the user saying we added the configuration value in plaintext. Fixes #552
Move from two top level commands
text
andsecret
to a singleset
command to set a value. To store a value encrypted, use
--secret
asan argument to
set
.Renames
ls
toget
. The command is otherwise unchanged, soget
with no additional arguments will print all the configuration values
for a stack (in a table format), while
get <key-name>
will print thevalue for that key by itself (useful for scripting).
Fixes #552