12 Commits (f2dbf80badc8c7385a7b44bb040ae5e8550e7e60)

Author	SHA1	Message	Date
Martin Atkins	39e609d5fd	vendor: switch to HCL 2.0 in the HCL repository ... Previously we were using the experimental HCL 2 repository, but now we'll shift over to the v2 import path within the main HCL repository as part of actually releasing HCL 2.0 as stable. This is a mechanical search/replace to the new import paths. It also switches to the v2.0.0 release of HCL, which includes some new code that Terraform didn't previously have but should not change any behavior that matters for Terraform's purposes. For the moment the experimental HCL2 repository is still an indirect dependency via terraform-config-inspect, so it remains in our go.sum and vendor directories for the moment. Because terraform-config-inspect uses a much smaller subset of the HCL2 functionality, this does still manage to prune the vendor directory a little. A subsequent release of terraform-config-inspect should allow us to completely remove that old repository in a future commit.	6 years ago
Martin Atkins	c937c06a03	terraform: ugly huge change to weave in new HCL2-oriented types ... Due to how deeply the configuration types go into Terraform Core, there isn't a great way to switch out to HCL2 gradually. As a consequence, this huge commit gets us from the old state to a _compilable_ new state, but does not yet attempt to fix any tests and has a number of known missing parts and bugs. We will continue to iterate on this in forthcoming commits, heading back towards passing tests and making Terraform fully-functional again. The three main goals here are: - Use the configuration models from the "configs" package instead of the older models in the "config" package, which is now deprecated and preserved only to help us write our migration tool. - Do expression inspection and evaluation using the functionality of the new "lang" package, instead of the Interpolator type and related functionality in the main "terraform" package. - Represent addresses of various objects using types in the addrs package, rather than hand-constructed strings. This is not critical to support the above, but was a big help during the implementation of these other points since it made it much more explicit what kind of address is expected in each context. Since our new packages are built to accommodate some future planned features that are not yet implemented (e.g. the "for_each" argument on resources, "count"/"for_each" on modules), and since there's still a fair amount of functionality still using old-style APIs, there is a moderate amount of shimming here to connect new assumptions with old, hopefully in a way that makes it easier to find and eliminate these shims later. I apologize in advance to the person who inevitably just found this huge commit while spelunking through the commit history.	7 years ago
Mitchell Hashimoto	77efacf30e	command: use helper/variables for flags and parsing	9 years ago
Mitchell Hashimoto	f9b0207304	command: FlagTypedKV parses bool as string ... When passing a bool type to a variable such as `-var foo=true`, the CLI would parse this as a `bool` type which Terraform core cannot handle. It would then error with an invalid type error. This changes the handling to convert the bool to its literally string value given on the command-line.	9 years ago
James Bardin	4f91507d05	Merge pull request #9268 from hashicorp/jbardin/hcl-maps ... Get rid of the list when parsing HCL maps for vars	9 years ago
James Bardin	9fc50a76c3	Get rid of the list when parsing HCL maps for vars ... When we parse a map from HCL, it's decoded into a list of maps because HCL allows declaring a key multiple times to implicitly add it to a list. Since there's no terraform variable configuration that supports this structure, we can always flatten a []map[string]interface{} value to a map[string]interface{} and remove any type rrors trying to apply that value.	10 years ago
James Bardin	cf1cfccf06	Don't parse a TestFlagTypedKV value as a number ... Don't try to parse a varibale as HCL if the value can be parse as a single number. HCL will always attempt to convert the value to a number, even if we later find the configured variable's type to be a string.	10 years ago
Mitchell Hashimoto	0a2b5de67f	command: more resilient HCL check for inputs	10 years ago
James Nugent	681d94ae20	core: Allow lists and maps as variable overrides ... Terraform 0.7 introduces lists and maps as first-class values for variables, in addition to string values which were previously available. However, there was previously no way to override the default value of a list or map, and the functionality for overriding specific map keys was broken. Using the environment variable method for setting variable values, there was previously no way to give a variable a value of a list or map. These now support HCL for individual values - specifying: TF_VAR_test='["Hello", "World"]' will set the variable `test` to a two-element list containing "Hello" and "World". Specifying TF_VAR_test_map='{"Hello = "World", "Foo" = "bar"}' will set the variable `test_map` to a two-element map with keys "Hello" and "Foo", and values "World" and "bar" respectively. The same logic is applied to `-var` flags, and the file parsed by `-var-files` ("autoVariables"). Note that care must be taken to not run into shell expansion for `-var-` flags and environment variables. We also merge map keys where appropriate. The override syntax has changed (to be noted in CHANGELOG as a breaking change), so several tests needed their syntax updating from the old `amis.us-east-1 = "newValue"` style to `amis = "{ "us-east-1" = "newValue"}"` style as defined in TF-002. In order to continue supporting the `-var "foo=bar"` type of variable flag (which is not valid HCL), a special case error is checked after HCL parsing fails, and the old code path runs instead.	10 years ago
Mitchell Hashimoto	a76105b0f1	command: make error message clearer for invalid tfvars format [GH-1889]	11 years ago
Paul Hinze	97acccd3ed	core: targeted operations ... Add `-target=resource` flag to core operations, allowing users to target specific resources in their infrastructure. When `-target` is used, the operation will only apply to that resource and its dependencies. The calculated dependencies are different depending on whether we're running a normal operation or a `terraform destroy`. Generally, "dependencies" refers to ancestors: resources falling _before_ the target in the graph, because their changes are required to accurately act on the target. For destroys, "dependencies" are descendents: those resources which fall _after_ the target. These resources depend on our target, which is going to be destroyed, so they should also be destroyed.	11 years ago
Mitchell Hashimoto	3550f7ac3a	command: FlagVar => FlagKV	11 years ago