terraform/internal/refactoring
Martin Atkins 7b99861b1c refactoring: Don't implicitly move for resources with for_each
Our previous rule for implicitly moving from IntKey(0) to NoKey would
apply that move even when the current resource configuration uses
for_each, because we were only considering whether "count" were set.

Previously this was relatively harmless because the resource instance in
question would end up planned for deletion anyway: neither an IntKey nor
a NoKey are valid keys for for_each.

Now that we're going to be announcing these moves explicitly in the UI,
it would be confusing to see Terraform report that IntKey moved to NoKey
in a situation where the config changed from count to for_each, so to
address that we'll only generate the implied statement if neither
repetition argument is set.
2021-09-23 14:37:08 -07:00
..
testdata refactoring: Don't implicitly move for resources with for_each 2021-09-23 14:37:08 -07:00
move_execute.go refactoring: ApplyMoves new return type 2021-09-22 09:01:10 -07:00
move_execute_test.go refactoring: ApplyMoves new return type 2021-09-22 09:01:10 -07:00
move_statement.go refactoring: Don't implicitly move for resources with for_each 2021-09-23 14:37:08 -07:00
move_statement_test.go refactoring: Don't implicitly move for resources with for_each 2021-09-23 14:37:08 -07:00
move_validate.go refactoring: First round of ValidateMoves rules 2021-07-29 12:29:36 -07:00
move_validate_test.go refactoring: ApplyMoves new return type 2021-09-22 09:01:10 -07:00