-
Notifications
You must be signed in to change notification settings - Fork 9.5k
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
TF 0.6: prompting for values even though default is defined #2592
Comments
@nathanielks thanks for the report! We actually noticed something similar as we rolled 0.6.0 out to Atlas. I'll do some more testing to figure out where the behavior change is coming from, but in the meantime you can always add the |
@phinze aha, thanks for that! |
@phinze would it be helpful if I started documentation on the various env variables? So far I'm aware of:
|
@nathanielks yeah might be worth gathering them all into one place - though we should probably categorize them since some are really only for development while others are actually useful to users |
Agreed with @phinze that we shouldn't doc the dev ones except for perhaps in the README or contributors guide. |
Will do. Where'd you like me to write those up? I can get started on that tonight. |
@nathanielks good question! perhaps a new "Environment Variables" page under "Configuration"? |
@phinze that sounds pretty good to me. |
I think the relevant code change here is #2502 |
Okay, so that code change uncovered the core bug here that's been hanging out for some time: terraform is prompting for any variables without values, even if they have defaults set. Tagged and we'll get this fixed up! |
whoop whoop! |
Okie doke, here's my first go at it: #2601 |
Thanks, just ran into this myself and caused some head scratching for me. |
In `helper/schema` we already makes a distinction between `Default` which is always applied and `InputDefault` which is displayed to the user for an empty field. But for variables we just have `Default` which is treated like `InputDefault`. This changes it to _not_ prompt the user for a value when the variable declaration includes a default. Treating this as a UX bugfix and the "don't prompt for variables w/ defaults set" behavior as the originally expected behavior we were failing to honor. Added an already-passing test to verify and cover the `helper/schema` behavior. Perhaps down the road we can add a `input_default` attribute to variables to allow similar behavior to `helper/schema` in variables, but for now just sticking with the fix. Fixes #2592
I'm afraid I'm still seeing this behavior after updating and building locally. In my case I'm using the OpenStack provider and not specifying the openstack.api_key and openstack.endpoint_type which aren't required (according to the docs) but am still getting prompted for them. (I suppose the docs could be wrong, but everything works as expected if I specify blank values for them so I suspect not.) |
Hi @RichSteele - this issue was specifically around variables (i.e. |
@RichSteele ah I hadn't seen this PR #2626 - will be fixed it 0.6.1! |
Awesome, thanks, I misread this defect. I hadn't thought to look through the pull requests for it. |
I would like to have an option of asking even if the default is set where simply pressing the |
@umeshksingla - I haven't seen any requests for that feature; you can open a feature request! |
@umeshksingla did you ever open a feature request for this? I would also like that feature very much! |
👍 |
@naumannt @codejamninja I did. Here #18702 |
@umeshksingla how do you control showing the default or not showing the default? |
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
Just updated to 0.6.0 and now variables that have defaults are prompting for a value. Ideally it would use the default value silently. I couldn't find any PR's or issues describing the new behavior. Is this intentional or oops?
The text was updated successfully, but these errors were encountered: