6 Commits (bfbab7100c19fc49975a7c1e5ef68b4bd307f480)

Author	SHA1	Message	Date
Martin Atkins	400038eda4	command: "terraform apply" uses interactive confirmation by default ... In the 0.10 release we added an opt-in mode where Terraform would prompt interactively for confirmation during apply. We made this opt-in to give those who wrap Terraform in automation some time to update their scripts to explicitly opt out of this behavior where appropriate. Here we switch the default so that a "terraform apply" with no arguments will -- if it computes a non-empty diff -- display the diff and wait for the user to type "yes" in similar vein to the "terraform destroy" command. This makes the commonly-used "terraform apply" a safe workflow for interactive use, so "terraform plan" is now mainly for use in automation where a separate planning step is used. The apply command remains non-interactive when given an explicit plan file. The previous behavior -- though not recommended -- can be obtained by explicitly setting the -auto-approve option on the apply command line, and indeed that is how all of the tests are updated here so that they can continue to run non-interactively.	9 years ago
Robert Liebowitz	8d98fdecac	Autoload only .auto.tfvars files	9 years ago
Robert Liebowitz	006744bfe0	Use all tfvars files in working directory ... As a side effect, several commands that previously did not have a failure state can now fail during meta-parameter processing.	9 years ago
David Glasser	039d36bf91	command: add "apply -auto-approve=false" flag ... A common reason to want to use `terraform plan` is to have a chance to review and confirm a plan before running it. If in fact that is the only reason you are running plan, this new `terraform apply -auto-approve=false` flag provides an easier alternative to P=$(mktemp -t plan) terraform refresh terraform plan -refresh=false -out=$P terraform apply $P rm $P The flag defaults to true for now, but in a future version of Terraform it will default to false.	9 years ago
Martin Atkins	a8c58b081c	core: -target option to also select resources in descendant modules ... Previously the behavior for -target when given a module address was to target only resources directly within that module, ignoring any resources defined in child modules. This behavior turned out to be counter-intuitive, since users expected the -target address to be interpreted hierarchically. We'll now use the new "Contains" function for addresses, which provides a hierarchical "containment" concept that is more consistent with user expectations. In particular, it allows module.foo to match module.foo.module.bar.aws_instance.baz, where before that would not have been true. Since Contains isn't commutative (unlike Equals) this requires some special handling for targeting specific indices. When given an argument like -target=aws_instance.foo[0], the initial graph construction (for both plan and refresh) is for the resource nodes from configuration, which have not yet been expanded to separate indexed instances. Thus we need to do the first pass of TargetsTransformer in mode where indices are ignored, with the work then completed by the DynamicExpand method which re-applies the TargetsTransformer in index-sensitive mode. This is a breaking change for anyone depending on the previous behavior of -target, since it will now select more resources than before. There is no way provided to obtain the previous behavior. Eventually we may support negative targeting, which could then combine with positive targets to regain the previous behavior as an explicit choice.	9 years ago
Martin Atkins	7ed70bb00e	website: new filesystem layout for core/provider split ... This repo now contains only the core docs, with other content moving elsewhere.	9 years ago