Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Override exactly according to the Terraform spec (#2124)
* Nested blocks should not be merged by overrides See https://developer.hashicorp.com/terraform/language/files/override#merging-behavior - Within a top-level block, any nested blocks within an override block replace all blocks of the same type in the original block. Any block types that do not appear in the override block remain from the original block. - The contents of nested configuration blocks are not merged. * Override lexicographical order See https://developer.hashicorp.com/terraform/language/files/override#merging-behavior If more than one override file defines the same top-level block, the overriding effect is compounded, with later blocks taking precedence over earlier blocks. Overrides are processed in order first by filename (in lexicographical order) and then by position in each file. Regarding the position in each file, no additional considerations are necessary since hclext.Blocks are already sorted. * Override "terraform" blocks See https://developer.hashicorp.com/terraform/language/files/override#merging-terraform-blocks The settings within terraform blocks are considered individually when merging. If the required_providers argument is set, its value is merged on an element-by-element basis, which allows an override block to adjust the constraint for a single provider without affecting the constraints for other providers. In both the required_version and required_providers settings, each override constraint entirely replaces the constraints for the same component in the original block. If both the base block and the override block both set required_version then the constraints in the base block are entirely ignored. The presence of a block defining a backend (either cloud or backend) in an override file always takes precedence over a block defining a backend in the original configuration. That is, if a cloud block is set within the original configuration and a backend block is set in the override file, Terraform will use the backend block specified in the override file upon merging. Similarly, if a backend block is set within the original configuration and a cloud block is set in the override file, Terraform will use the cloud block specified in the override file upon merging. * Override "locals" blocks See also https://developer.hashicorp.com/terraform/language/files/override#merging-locals-blocks Each locals block defines a number of named values. Overrides are applied on a value-by-value basis, ignoring which locals block they are defined in. * Override "resource" blocks See https://developer.hashicorp.com/terraform/language/files/override#merging-resource-and-data-blocks Within a resource block, the contents of any lifecycle nested block are merged on an argument-by-argument basis. For example, if an override block sets only the create_before_destroy argument then any ignore_changes argument in the original block will be preserved. If an overriding resource block contains one or more provisioner blocks then any provisioner blocks in the original block are ignored. If an overriding resource block contains a connection block then it completely overrides any connection block present in the original block. * refactor * Merge locals/required_providers if possible If there is only a single locals/required_providers in the primary, we will merge it rather than append it to maintain backwards compatibility. * Do not sort override files in PartialContent For optimal performance, sort override files at parse time instead of sorting in PartialContent all the time. * Add E2E test for overriding required providers
- Loading branch information