This commit tests whether an interface is nil before type asserting it
to string - this should fix the panic reported in #8609.
We also clean up the schema definition to the newer style without
redundant type declarations.
Related to #5254
If the count of a resource is interpolated (i.e. `${var.c}`), then it
must be interpolated before any splat variable using that resource can
be used (i.e. `type.name.*.attr`). The original fix for #5254 is to
always ensure that this is the case.
While working on a new apply builder based on the diff in
`f-apply-builder`, this truth no longer always holds. Rather than always
include such a resource, I believe the correct behavior instead is to
use the state as a source of truth during `walkApply` operations.
This change specifically is scoped to `walkApply` operation
interpolations since we know the state of any multi-variable should be
available. The behavior is less clear for other operations so I left the
logic unchanged from prior versions.
Specified that the security group needs to be addressed by it's id and not by its name. This will assist when debugging the error with message "{name} is invalid. Expect fully qualified resource Id that start with azure .properties.networkSecurityGroup.id"
The Deposed slice wasn't being normalized and nil values could be read
in from a state file. Filter out the nils during init. There is
still a bug in copystructure, but that will be addressed separately.
A nil InstanceState within State/Modules/Resources/Deposed will panic
during a deep copy. The panic needs to be fixed in copystructure, but
the nil probably should have been normalized out before we got here too.
With the addition of github_repository it may be confusing that
github_team_repository only creates relationships, rather than creating
actual repositories. To reduce the chance of confusion, we'll make this
explicit in the docs for github_team_repository.
Also taking this opportunity to make the examples consistent with what
would be produced by hclfmt.
Make sure to hash base64 decoded value since user_data might be given
either raw bytes or base64 value.
This helps https://github.com/hashicorp/terraform/issues/1887 somewhat
as now you can:
1) Update user_data in AWS console.
2) Respectively update user_data in terraform code.
3) Just refresh terraform state and it should not report any changes.
Mitchell Hashimoto