ResiLien
/
terraform
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
terraform/internal/addrs/move_endpoint_test.go

633 lines
13 KiB
Go
Raw Normal View History

addrs: AbsMoveable, ConfigMoveable, and MoveableEndpoint These three types represent the three different address representations we need to represent different stages of analysis for "moved" blocks in the configuration. The goal here is to encapsulate all of the static address wrangling inside these types so that users of these types elsewhere would have to work pretty hard to use them incorrectly. In particular, the MovableEndpoint type intentionally fully encapsulates the weird relative addresses we use in configuration so that code elsewhere in Terraform can never end up holding an address of a type that suggests absolute when it's actually relative. That situation only occurs in the internals of MoveableEndpoint where we use not-really-absolute AbsMoveable address types to represent the not-yet-resolved relative addresses. This only takes care of the static address wrangling. There's lots of other rules for what makes a "moved" block valid which will need to be checked elsewhere because they require more context than just the content of the address itself.
2021-06-30 04:03:59 +02:00
package addrs
import (
"fmt"
"testing"
"github.com/google/go-cmp/cmp"
"github.com/hashicorp/hcl/v2"
"github.com/hashicorp/hcl/v2/hclsyntax"
)
func TestParseMoveEndpoint(t *testing.T) {
tests := []struct {
Input string
remove occurrences of AbsMovable
2021-11-15 11:46:06 +01:00
WantRel AbsMoveable // funny intermediate subset of AbsMoveable
addrs: AbsMoveable, ConfigMoveable, and MoveableEndpoint These three types represent the three different address representations we need to represent different stages of analysis for "moved" blocks in the configuration. The goal here is to encapsulate all of the static address wrangling inside these types so that users of these types elsewhere would have to work pretty hard to use them incorrectly. In particular, the MovableEndpoint type intentionally fully encapsulates the weird relative addresses we use in configuration so that code elsewhere in Terraform can never end up holding an address of a type that suggests absolute when it's actually relative. That situation only occurs in the internals of MoveableEndpoint where we use not-really-absolute AbsMoveable address types to represent the not-yet-resolved relative addresses. This only takes care of the static address wrangling. There's lots of other rules for what makes a "moved" block valid which will need to be checked elsewhere because they require more context than just the content of the address itself.
2021-06-30 04:03:59 +02:00
WantErr string
}{
{
`foo.bar`,
AbsResourceInstance{
Module: RootModuleInstance,
Resource: ResourceInstance{
Resource: Resource{
Mode: ManagedResourceMode,
Type: "foo",
Name: "bar",
},
Key: NoKey,
},
},
``,
},
{
`foo.bar[0]`,
AbsResourceInstance{
Module: RootModuleInstance,
Resource: ResourceInstance{
Resource: Resource{
Mode: ManagedResourceMode,
Type: "foo",
Name: "bar",
},
Key: IntKey(0),
},
},
``,
},
{
`foo.bar["a"]`,
AbsResourceInstance{
Module: RootModuleInstance,
Resource: ResourceInstance{
Resource: Resource{
Mode: ManagedResourceMode,
Type: "foo",
Name: "bar",
},
Key: StringKey("a"),
},
},
``,
},
{
`module.boop.foo.bar`,
AbsResourceInstance{
Module: ModuleInstance{
ModuleInstanceStep{Name: "boop"},
},
Resource: ResourceInstance{
Resource: Resource{
Mode: ManagedResourceMode,
Type: "foo",
Name: "bar",
},
Key: NoKey,
},
},
``,
},
{
`module.boop.foo.bar[0]`,
AbsResourceInstance{
Module: ModuleInstance{
ModuleInstanceStep{Name: "boop"},
},
Resource: ResourceInstance{
Resource: Resource{
Mode: ManagedResourceMode,
Type: "foo",
Name: "bar",
},
Key: IntKey(0),
},
},
``,
},
{
`module.boop.foo.bar["a"]`,
AbsResourceInstance{
Module: ModuleInstance{
ModuleInstanceStep{Name: "boop"},
},
Resource: ResourceInstance{
Resource: Resource{
Mode: ManagedResourceMode,
Type: "foo",
Name: "bar",
},
Key: StringKey("a"),
},
},
``,
},
{
`data.foo.bar`,
AbsResourceInstance{
Module: RootModuleInstance,
Resource: ResourceInstance{
Resource: Resource{
Mode: DataResourceMode,
Type: "foo",
Name: "bar",
},
Key: NoKey,
},
},
``,
},
{
`data.foo.bar[0]`,
AbsResourceInstance{
Module: RootModuleInstance,
Resource: ResourceInstance{
Resource: Resource{
Mode: DataResourceMode,
Type: "foo",
Name: "bar",
},
Key: IntKey(0),
},
},
``,
},
{
`data.foo.bar["a"]`,
AbsResourceInstance{
Module: RootModuleInstance,
Resource: ResourceInstance{
Resource: Resource{
Mode: DataResourceMode,
Type: "foo",
Name: "bar",
},
Key: StringKey("a"),
},
},
``,
},
{
`module.boop.data.foo.bar`,
AbsResourceInstance{
Module: ModuleInstance{
ModuleInstanceStep{Name: "boop"},
},
Resource: ResourceInstance{
Resource: Resource{
Mode: DataResourceMode,
Type: "foo",
Name: "bar",
},
Key: NoKey,
},
},
``,
},
{
`module.boop.data.foo.bar[0]`,
AbsResourceInstance{
Module: ModuleInstance{
ModuleInstanceStep{Name: "boop"},
},
Resource: ResourceInstance{
Resource: Resource{
Mode: DataResourceMode,
Type: "foo",
Name: "bar",
},
Key: IntKey(0),
},
},
``,
},
{
`module.boop.data.foo.bar["a"]`,
AbsResourceInstance{
Module: ModuleInstance{
ModuleInstanceStep{Name: "boop"},
},
Resource: ResourceInstance{
Resource: Resource{
Mode: DataResourceMode,
Type: "foo",
Name: "bar",
},
Key: StringKey("a"),
},
},
``,
},
{
`module.foo`,
ModuleInstance{
ModuleInstanceStep{Name: "foo"},
},
``,
},
{
`module.foo[0]`,
ModuleInstance{
ModuleInstanceStep{Name: "foo", InstanceKey: IntKey(0)},
},
``,
},
{
`module.foo["a"]`,
ModuleInstance{
ModuleInstanceStep{Name: "foo", InstanceKey: StringKey("a")},
},
``,
},
{
`module.foo.module.bar`,
ModuleInstance{
ModuleInstanceStep{Name: "foo"},
ModuleInstanceStep{Name: "bar"},
},
``,
},
{
`module.foo[1].module.bar`,
ModuleInstance{
ModuleInstanceStep{Name: "foo", InstanceKey: IntKey(1)},
ModuleInstanceStep{Name: "bar"},
},
``,
},
{
`module.foo.module.bar[1]`,
ModuleInstance{
ModuleInstanceStep{Name: "foo"},
ModuleInstanceStep{Name: "bar", InstanceKey: IntKey(1)},
},
``,
},
{
`module.foo[0].module.bar[1]`,
ModuleInstance{
ModuleInstanceStep{Name: "foo", InstanceKey: IntKey(0)},
ModuleInstanceStep{Name: "bar", InstanceKey: IntKey(1)},
},
``,
},
{
`module`,
nil,
`Invalid address operator: Prefix "module." must be followed by a module name.`,
},
{
`module[0]`,
nil,
`Invalid address operator: Prefix "module." must be followed by a module name.`,
},
{
`module.foo.data`,
nil,
`Invalid address: Resource specification must include a resource type and name.`,
},
{
`module.foo.data.bar`,
nil,
`Invalid address: Resource specification must include a resource type and name.`,
},
{
`module.foo.data[0]`,
nil,
`Invalid address: Resource specification must include a resource type and name.`,
},
{
`module.foo.data.bar[0]`,
nil,
`Invalid address: A resource name is required.`,
},
{
`module.foo.bar`,
nil,
`Invalid address: Resource specification must include a resource type and name.`,
},
{
`module.foo.bar[0]`,
nil,
`Invalid address: A resource name is required.`,
},
}
for _, test := range tests {
t.Run(test.Input, func(t *testing.T) {
traversal, hclDiags := hclsyntax.ParseTraversalAbs([]byte(test.Input), "", hcl.InitialPos)
if hclDiags.HasErrors() {
// We're not trying to test the HCL parser here, so any
// failures at this point are likely to be bugs in the
// test case itself.
t.Fatalf("syntax error: %s", hclDiags.Error())
}
moveEp, diags := ParseMoveEndpoint(traversal)
switch {
case test.WantErr != "":
if !diags.HasErrors() {
t.Fatalf("unexpected success\nwant error: %s", test.WantErr)
}
gotErr := diags.Err().Error()
if gotErr != test.WantErr {
t.Fatalf("wrong error\ngot: %s\nwant: %s", gotErr, test.WantErr)
}
default:
if diags.HasErrors() {
t.Fatalf("unexpected error: %s", diags.Err().Error())
}
if diff := cmp.Diff(test.WantRel, moveEp.relSubject); diff != "" {
t.Errorf("wrong result\n%s", diff)
}
}
})
}
}
func TestUnifyMoveEndpoints(t *testing.T) {
tests := []struct {
InputFrom, InputTo string
addrs: MoveEndpointInModule We previously built out addrs.UnifyMoveEndpoints with a different implementation strategy in mind, but that design turns out to not be viable because it forces us to move to AbsMoveable addresses too soon, before we've done the analysis required to identify chained and nested moves. Instead, UnifyMoveEndpoints will return a new type MoveEndpointInModule which conceptually represents a matching pattern which either matches or doesn't match a particular AbsMoveable. It does this by just binding the unified relative address from the MoveEndpoint to the module where it was declared, and thus allows us to distinguish between the part of the module path which applies to any instances of the given modules vs. the user-specified part which must identify particular module instances.
2021-07-12 21:23:10 +02:00
Module Module
WantFrom, WantTo string
addrs: AbsMoveable, ConfigMoveable, and MoveableEndpoint These three types represent the three different address representations we need to represent different stages of analysis for "moved" blocks in the configuration. The goal here is to encapsulate all of the static address wrangling inside these types so that users of these types elsewhere would have to work pretty hard to use them incorrectly. In particular, the MovableEndpoint type intentionally fully encapsulates the weird relative addresses we use in configuration so that code elsewhere in Terraform can never end up holding an address of a type that suggests absolute when it's actually relative. That situation only occurs in the internals of MoveableEndpoint where we use not-really-absolute AbsMoveable address types to represent the not-yet-resolved relative addresses. This only takes care of the static address wrangling. There's lots of other rules for what makes a "moved" block valid which will need to be checked elsewhere because they require more context than just the content of the address itself.
2021-06-30 04:03:59 +02:00
}{
{
InputFrom: `foo.bar`,
InputTo: `foo.baz`,
addrs: MoveEndpointInModule We previously built out addrs.UnifyMoveEndpoints with a different implementation strategy in mind, but that design turns out to not be viable because it forces us to move to AbsMoveable addresses too soon, before we've done the analysis required to identify chained and nested moves. Instead, UnifyMoveEndpoints will return a new type MoveEndpointInModule which conceptually represents a matching pattern which either matches or doesn't match a particular AbsMoveable. It does this by just binding the unified relative address from the MoveEndpoint to the module where it was declared, and thus allows us to distinguish between the part of the module path which applies to any instances of the given modules vs. the user-specified part which must identify particular module instances.
2021-07-12 21:23:10 +02:00
Module: RootModule,
WantFrom: `foo.bar[*]`,
WantTo: `foo.baz[*]`,
addrs: AbsMoveable, ConfigMoveable, and MoveableEndpoint These three types represent the three different address representations we need to represent different stages of analysis for "moved" blocks in the configuration. The goal here is to encapsulate all of the static address wrangling inside these types so that users of these types elsewhere would have to work pretty hard to use them incorrectly. In particular, the MovableEndpoint type intentionally fully encapsulates the weird relative addresses we use in configuration so that code elsewhere in Terraform can never end up holding an address of a type that suggests absolute when it's actually relative. That situation only occurs in the internals of MoveableEndpoint where we use not-really-absolute AbsMoveable address types to represent the not-yet-resolved relative addresses. This only takes care of the static address wrangling. There's lots of other rules for what makes a "moved" block valid which will need to be checked elsewhere because they require more context than just the content of the address itself.
2021-06-30 04:03:59 +02:00
},
{
InputFrom: `foo.bar`,
InputTo: `foo.baz`,
addrs: MoveEndpointInModule We previously built out addrs.UnifyMoveEndpoints with a different implementation strategy in mind, but that design turns out to not be viable because it forces us to move to AbsMoveable addresses too soon, before we've done the analysis required to identify chained and nested moves. Instead, UnifyMoveEndpoints will return a new type MoveEndpointInModule which conceptually represents a matching pattern which either matches or doesn't match a particular AbsMoveable. It does this by just binding the unified relative address from the MoveEndpoint to the module where it was declared, and thus allows us to distinguish between the part of the module path which applies to any instances of the given modules vs. the user-specified part which must identify particular module instances.
2021-07-12 21:23:10 +02:00
Module: RootModule.Child("a"),
WantFrom: `module.a[*].foo.bar[*]`,
WantTo: `module.a[*].foo.baz[*]`,
addrs: AbsMoveable, ConfigMoveable, and MoveableEndpoint These three types represent the three different address representations we need to represent different stages of analysis for "moved" blocks in the configuration. The goal here is to encapsulate all of the static address wrangling inside these types so that users of these types elsewhere would have to work pretty hard to use them incorrectly. In particular, the MovableEndpoint type intentionally fully encapsulates the weird relative addresses we use in configuration so that code elsewhere in Terraform can never end up holding an address of a type that suggests absolute when it's actually relative. That situation only occurs in the internals of MoveableEndpoint where we use not-really-absolute AbsMoveable address types to represent the not-yet-resolved relative addresses. This only takes care of the static address wrangling. There's lots of other rules for what makes a "moved" block valid which will need to be checked elsewhere because they require more context than just the content of the address itself.
2021-06-30 04:03:59 +02:00
},
{
InputFrom: `foo.bar`,
InputTo: `module.b[0].foo.baz`,
addrs: MoveEndpointInModule We previously built out addrs.UnifyMoveEndpoints with a different implementation strategy in mind, but that design turns out to not be viable because it forces us to move to AbsMoveable addresses too soon, before we've done the analysis required to identify chained and nested moves. Instead, UnifyMoveEndpoints will return a new type MoveEndpointInModule which conceptually represents a matching pattern which either matches or doesn't match a particular AbsMoveable. It does this by just binding the unified relative address from the MoveEndpoint to the module where it was declared, and thus allows us to distinguish between the part of the module path which applies to any instances of the given modules vs. the user-specified part which must identify particular module instances.
2021-07-12 21:23:10 +02:00
Module: RootModule.Child("a"),
WantFrom: `module.a[*].foo.bar[*]`,
WantTo: `module.a[*].module.b[0].foo.baz[*]`,
addrs: AbsMoveable, ConfigMoveable, and MoveableEndpoint These three types represent the three different address representations we need to represent different stages of analysis for "moved" blocks in the configuration. The goal here is to encapsulate all of the static address wrangling inside these types so that users of these types elsewhere would have to work pretty hard to use them incorrectly. In particular, the MovableEndpoint type intentionally fully encapsulates the weird relative addresses we use in configuration so that code elsewhere in Terraform can never end up holding an address of a type that suggests absolute when it's actually relative. That situation only occurs in the internals of MoveableEndpoint where we use not-really-absolute AbsMoveable address types to represent the not-yet-resolved relative addresses. This only takes care of the static address wrangling. There's lots of other rules for what makes a "moved" block valid which will need to be checked elsewhere because they require more context than just the content of the address itself.
2021-06-30 04:03:59 +02:00
},
{
InputFrom: `foo.bar`,
InputTo: `foo.bar["thing"]`,
addrs: MoveEndpointInModule We previously built out addrs.UnifyMoveEndpoints with a different implementation strategy in mind, but that design turns out to not be viable because it forces us to move to AbsMoveable addresses too soon, before we've done the analysis required to identify chained and nested moves. Instead, UnifyMoveEndpoints will return a new type MoveEndpointInModule which conceptually represents a matching pattern which either matches or doesn't match a particular AbsMoveable. It does this by just binding the unified relative address from the MoveEndpoint to the module where it was declared, and thus allows us to distinguish between the part of the module path which applies to any instances of the given modules vs. the user-specified part which must identify particular module instances.
2021-07-12 21:23:10 +02:00
Module: RootModule,
WantFrom: `foo.bar`,
WantTo: `foo.bar["thing"]`,
addrs: AbsMoveable, ConfigMoveable, and MoveableEndpoint These three types represent the three different address representations we need to represent different stages of analysis for "moved" blocks in the configuration. The goal here is to encapsulate all of the static address wrangling inside these types so that users of these types elsewhere would have to work pretty hard to use them incorrectly. In particular, the MovableEndpoint type intentionally fully encapsulates the weird relative addresses we use in configuration so that code elsewhere in Terraform can never end up holding an address of a type that suggests absolute when it's actually relative. That situation only occurs in the internals of MoveableEndpoint where we use not-really-absolute AbsMoveable address types to represent the not-yet-resolved relative addresses. This only takes care of the static address wrangling. There's lots of other rules for what makes a "moved" block valid which will need to be checked elsewhere because they require more context than just the content of the address itself.
2021-06-30 04:03:59 +02:00
},
{
InputFrom: `foo.bar["thing"]`,
InputTo: `foo.bar`,
addrs: MoveEndpointInModule We previously built out addrs.UnifyMoveEndpoints with a different implementation strategy in mind, but that design turns out to not be viable because it forces us to move to AbsMoveable addresses too soon, before we've done the analysis required to identify chained and nested moves. Instead, UnifyMoveEndpoints will return a new type MoveEndpointInModule which conceptually represents a matching pattern which either matches or doesn't match a particular AbsMoveable. It does this by just binding the unified relative address from the MoveEndpoint to the module where it was declared, and thus allows us to distinguish between the part of the module path which applies to any instances of the given modules vs. the user-specified part which must identify particular module instances.
2021-07-12 21:23:10 +02:00
Module: RootModule,
WantFrom: `foo.bar["thing"]`,
WantTo: `foo.bar`,
addrs: AbsMoveable, ConfigMoveable, and MoveableEndpoint These three types represent the three different address representations we need to represent different stages of analysis for "moved" blocks in the configuration. The goal here is to encapsulate all of the static address wrangling inside these types so that users of these types elsewhere would have to work pretty hard to use them incorrectly. In particular, the MovableEndpoint type intentionally fully encapsulates the weird relative addresses we use in configuration so that code elsewhere in Terraform can never end up holding an address of a type that suggests absolute when it's actually relative. That situation only occurs in the internals of MoveableEndpoint where we use not-really-absolute AbsMoveable address types to represent the not-yet-resolved relative addresses. This only takes care of the static address wrangling. There's lots of other rules for what makes a "moved" block valid which will need to be checked elsewhere because they require more context than just the content of the address itself.
2021-06-30 04:03:59 +02:00
},
{
InputFrom: `foo.bar["a"]`,
InputTo: `foo.bar["b"]`,
addrs: MoveEndpointInModule We previously built out addrs.UnifyMoveEndpoints with a different implementation strategy in mind, but that design turns out to not be viable because it forces us to move to AbsMoveable addresses too soon, before we've done the analysis required to identify chained and nested moves. Instead, UnifyMoveEndpoints will return a new type MoveEndpointInModule which conceptually represents a matching pattern which either matches or doesn't match a particular AbsMoveable. It does this by just binding the unified relative address from the MoveEndpoint to the module where it was declared, and thus allows us to distinguish between the part of the module path which applies to any instances of the given modules vs. the user-specified part which must identify particular module instances.
2021-07-12 21:23:10 +02:00
Module: RootModule,
WantFrom: `foo.bar["a"]`,
WantTo: `foo.bar["b"]`,
addrs: AbsMoveable, ConfigMoveable, and MoveableEndpoint These three types represent the three different address representations we need to represent different stages of analysis for "moved" blocks in the configuration. The goal here is to encapsulate all of the static address wrangling inside these types so that users of these types elsewhere would have to work pretty hard to use them incorrectly. In particular, the MovableEndpoint type intentionally fully encapsulates the weird relative addresses we use in configuration so that code elsewhere in Terraform can never end up holding an address of a type that suggests absolute when it's actually relative. That situation only occurs in the internals of MoveableEndpoint where we use not-really-absolute AbsMoveable address types to represent the not-yet-resolved relative addresses. This only takes care of the static address wrangling. There's lots of other rules for what makes a "moved" block valid which will need to be checked elsewhere because they require more context than just the content of the address itself.
2021-06-30 04:03:59 +02:00
},
{
InputFrom: `module.foo`,
InputTo: `module.bar`,
addrs: MoveEndpointInModule We previously built out addrs.UnifyMoveEndpoints with a different implementation strategy in mind, but that design turns out to not be viable because it forces us to move to AbsMoveable addresses too soon, before we've done the analysis required to identify chained and nested moves. Instead, UnifyMoveEndpoints will return a new type MoveEndpointInModule which conceptually represents a matching pattern which either matches or doesn't match a particular AbsMoveable. It does this by just binding the unified relative address from the MoveEndpoint to the module where it was declared, and thus allows us to distinguish between the part of the module path which applies to any instances of the given modules vs. the user-specified part which must identify particular module instances.
2021-07-12 21:23:10 +02:00
Module: RootModule,
WantFrom: `module.foo[*]`,
WantTo: `module.bar[*]`,
addrs: AbsMoveable, ConfigMoveable, and MoveableEndpoint These three types represent the three different address representations we need to represent different stages of analysis for "moved" blocks in the configuration. The goal here is to encapsulate all of the static address wrangling inside these types so that users of these types elsewhere would have to work pretty hard to use them incorrectly. In particular, the MovableEndpoint type intentionally fully encapsulates the weird relative addresses we use in configuration so that code elsewhere in Terraform can never end up holding an address of a type that suggests absolute when it's actually relative. That situation only occurs in the internals of MoveableEndpoint where we use not-really-absolute AbsMoveable address types to represent the not-yet-resolved relative addresses. This only takes care of the static address wrangling. There's lots of other rules for what makes a "moved" block valid which will need to be checked elsewhere because they require more context than just the content of the address itself.
2021-06-30 04:03:59 +02:00
},
{
InputFrom: `module.foo`,
InputTo: `module.bar.module.baz`,
addrs: MoveEndpointInModule We previously built out addrs.UnifyMoveEndpoints with a different implementation strategy in mind, but that design turns out to not be viable because it forces us to move to AbsMoveable addresses too soon, before we've done the analysis required to identify chained and nested moves. Instead, UnifyMoveEndpoints will return a new type MoveEndpointInModule which conceptually represents a matching pattern which either matches or doesn't match a particular AbsMoveable. It does this by just binding the unified relative address from the MoveEndpoint to the module where it was declared, and thus allows us to distinguish between the part of the module path which applies to any instances of the given modules vs. the user-specified part which must identify particular module instances.
2021-07-12 21:23:10 +02:00
Module: RootModule,
WantFrom: `module.foo[*]`,
WantTo: `module.bar.module.baz[*]`,
addrs: AbsMoveable, ConfigMoveable, and MoveableEndpoint These three types represent the three different address representations we need to represent different stages of analysis for "moved" blocks in the configuration. The goal here is to encapsulate all of the static address wrangling inside these types so that users of these types elsewhere would have to work pretty hard to use them incorrectly. In particular, the MovableEndpoint type intentionally fully encapsulates the weird relative addresses we use in configuration so that code elsewhere in Terraform can never end up holding an address of a type that suggests absolute when it's actually relative. That situation only occurs in the internals of MoveableEndpoint where we use not-really-absolute AbsMoveable address types to represent the not-yet-resolved relative addresses. This only takes care of the static address wrangling. There's lots of other rules for what makes a "moved" block valid which will need to be checked elsewhere because they require more context than just the content of the address itself.
2021-06-30 04:03:59 +02:00
},
{
InputFrom: `module.foo`,
InputTo: `module.bar.module.baz`,
addrs: MoveEndpointInModule We previously built out addrs.UnifyMoveEndpoints with a different implementation strategy in mind, but that design turns out to not be viable because it forces us to move to AbsMoveable addresses too soon, before we've done the analysis required to identify chained and nested moves. Instead, UnifyMoveEndpoints will return a new type MoveEndpointInModule which conceptually represents a matching pattern which either matches or doesn't match a particular AbsMoveable. It does this by just binding the unified relative address from the MoveEndpoint to the module where it was declared, and thus allows us to distinguish between the part of the module path which applies to any instances of the given modules vs. the user-specified part which must identify particular module instances.
2021-07-12 21:23:10 +02:00
Module: RootModule.Child("bloop"),
WantFrom: `module.bloop[*].module.foo[*]`,
WantTo: `module.bloop[*].module.bar.module.baz[*]`,
addrs: AbsMoveable, ConfigMoveable, and MoveableEndpoint These three types represent the three different address representations we need to represent different stages of analysis for "moved" blocks in the configuration. The goal here is to encapsulate all of the static address wrangling inside these types so that users of these types elsewhere would have to work pretty hard to use them incorrectly. In particular, the MovableEndpoint type intentionally fully encapsulates the weird relative addresses we use in configuration so that code elsewhere in Terraform can never end up holding an address of a type that suggests absolute when it's actually relative. That situation only occurs in the internals of MoveableEndpoint where we use not-really-absolute AbsMoveable address types to represent the not-yet-resolved relative addresses. This only takes care of the static address wrangling. There's lots of other rules for what makes a "moved" block valid which will need to be checked elsewhere because they require more context than just the content of the address itself.
2021-06-30 04:03:59 +02:00
},
{
InputFrom: `module.foo[0]`,
InputTo: `module.foo["a"]`,
addrs: MoveEndpointInModule We previously built out addrs.UnifyMoveEndpoints with a different implementation strategy in mind, but that design turns out to not be viable because it forces us to move to AbsMoveable addresses too soon, before we've done the analysis required to identify chained and nested moves. Instead, UnifyMoveEndpoints will return a new type MoveEndpointInModule which conceptually represents a matching pattern which either matches or doesn't match a particular AbsMoveable. It does this by just binding the unified relative address from the MoveEndpoint to the module where it was declared, and thus allows us to distinguish between the part of the module path which applies to any instances of the given modules vs. the user-specified part which must identify particular module instances.
2021-07-12 21:23:10 +02:00
Module: RootModule,
WantFrom: `module.foo[0]`,
WantTo: `module.foo["a"]`,
addrs: AbsMoveable, ConfigMoveable, and MoveableEndpoint These three types represent the three different address representations we need to represent different stages of analysis for "moved" blocks in the configuration. The goal here is to encapsulate all of the static address wrangling inside these types so that users of these types elsewhere would have to work pretty hard to use them incorrectly. In particular, the MovableEndpoint type intentionally fully encapsulates the weird relative addresses we use in configuration so that code elsewhere in Terraform can never end up holding an address of a type that suggests absolute when it's actually relative. That situation only occurs in the internals of MoveableEndpoint where we use not-really-absolute AbsMoveable address types to represent the not-yet-resolved relative addresses. This only takes care of the static address wrangling. There's lots of other rules for what makes a "moved" block valid which will need to be checked elsewhere because they require more context than just the content of the address itself.
2021-06-30 04:03:59 +02:00
},
{
InputFrom: `module.foo`,
InputTo: `module.foo["a"]`,
addrs: MoveEndpointInModule We previously built out addrs.UnifyMoveEndpoints with a different implementation strategy in mind, but that design turns out to not be viable because it forces us to move to AbsMoveable addresses too soon, before we've done the analysis required to identify chained and nested moves. Instead, UnifyMoveEndpoints will return a new type MoveEndpointInModule which conceptually represents a matching pattern which either matches or doesn't match a particular AbsMoveable. It does this by just binding the unified relative address from the MoveEndpoint to the module where it was declared, and thus allows us to distinguish between the part of the module path which applies to any instances of the given modules vs. the user-specified part which must identify particular module instances.
2021-07-12 21:23:10 +02:00
Module: RootModule,
WantFrom: `module.foo`,
WantTo: `module.foo["a"]`,
addrs: AbsMoveable, ConfigMoveable, and MoveableEndpoint These three types represent the three different address representations we need to represent different stages of analysis for "moved" blocks in the configuration. The goal here is to encapsulate all of the static address wrangling inside these types so that users of these types elsewhere would have to work pretty hard to use them incorrectly. In particular, the MovableEndpoint type intentionally fully encapsulates the weird relative addresses we use in configuration so that code elsewhere in Terraform can never end up holding an address of a type that suggests absolute when it's actually relative. That situation only occurs in the internals of MoveableEndpoint where we use not-really-absolute AbsMoveable address types to represent the not-yet-resolved relative addresses. This only takes care of the static address wrangling. There's lots of other rules for what makes a "moved" block valid which will need to be checked elsewhere because they require more context than just the content of the address itself.
2021-06-30 04:03:59 +02:00
},
{
InputFrom: `module.foo[0]`,
InputTo: `module.foo`,
addrs: MoveEndpointInModule We previously built out addrs.UnifyMoveEndpoints with a different implementation strategy in mind, but that design turns out to not be viable because it forces us to move to AbsMoveable addresses too soon, before we've done the analysis required to identify chained and nested moves. Instead, UnifyMoveEndpoints will return a new type MoveEndpointInModule which conceptually represents a matching pattern which either matches or doesn't match a particular AbsMoveable. It does this by just binding the unified relative address from the MoveEndpoint to the module where it was declared, and thus allows us to distinguish between the part of the module path which applies to any instances of the given modules vs. the user-specified part which must identify particular module instances.
2021-07-12 21:23:10 +02:00
Module: RootModule,
WantFrom: `module.foo[0]`,
WantTo: `module.foo`,
addrs: AbsMoveable, ConfigMoveable, and MoveableEndpoint These three types represent the three different address representations we need to represent different stages of analysis for "moved" blocks in the configuration. The goal here is to encapsulate all of the static address wrangling inside these types so that users of these types elsewhere would have to work pretty hard to use them incorrectly. In particular, the MovableEndpoint type intentionally fully encapsulates the weird relative addresses we use in configuration so that code elsewhere in Terraform can never end up holding an address of a type that suggests absolute when it's actually relative. That situation only occurs in the internals of MoveableEndpoint where we use not-really-absolute AbsMoveable address types to represent the not-yet-resolved relative addresses. This only takes care of the static address wrangling. There's lots of other rules for what makes a "moved" block valid which will need to be checked elsewhere because they require more context than just the content of the address itself.
2021-06-30 04:03:59 +02:00
},
{
InputFrom: `module.foo[0]`,
InputTo: `module.foo`,
addrs: MoveEndpointInModule We previously built out addrs.UnifyMoveEndpoints with a different implementation strategy in mind, but that design turns out to not be viable because it forces us to move to AbsMoveable addresses too soon, before we've done the analysis required to identify chained and nested moves. Instead, UnifyMoveEndpoints will return a new type MoveEndpointInModule which conceptually represents a matching pattern which either matches or doesn't match a particular AbsMoveable. It does this by just binding the unified relative address from the MoveEndpoint to the module where it was declared, and thus allows us to distinguish between the part of the module path which applies to any instances of the given modules vs. the user-specified part which must identify particular module instances.
2021-07-12 21:23:10 +02:00
Module: RootModule.Child("bloop"),
WantFrom: `module.bloop[*].module.foo[0]`,
WantTo: `module.bloop[*].module.foo`,
addrs: AbsMoveable, ConfigMoveable, and MoveableEndpoint These three types represent the three different address representations we need to represent different stages of analysis for "moved" blocks in the configuration. The goal here is to encapsulate all of the static address wrangling inside these types so that users of these types elsewhere would have to work pretty hard to use them incorrectly. In particular, the MovableEndpoint type intentionally fully encapsulates the weird relative addresses we use in configuration so that code elsewhere in Terraform can never end up holding an address of a type that suggests absolute when it's actually relative. That situation only occurs in the internals of MoveableEndpoint where we use not-really-absolute AbsMoveable address types to represent the not-yet-resolved relative addresses. This only takes care of the static address wrangling. There's lots of other rules for what makes a "moved" block valid which will need to be checked elsewhere because they require more context than just the content of the address itself.
2021-06-30 04:03:59 +02:00
},
{
InputFrom: `module.foo`,
InputTo: `foo.bar`,
addrs: MoveEndpointInModule We previously built out addrs.UnifyMoveEndpoints with a different implementation strategy in mind, but that design turns out to not be viable because it forces us to move to AbsMoveable addresses too soon, before we've done the analysis required to identify chained and nested moves. Instead, UnifyMoveEndpoints will return a new type MoveEndpointInModule which conceptually represents a matching pattern which either matches or doesn't match a particular AbsMoveable. It does this by just binding the unified relative address from the MoveEndpoint to the module where it was declared, and thus allows us to distinguish between the part of the module path which applies to any instances of the given modules vs. the user-specified part which must identify particular module instances.
2021-07-12 21:23:10 +02:00
Module: RootModule,
WantFrom: ``, // Can't unify module call with resource
WantTo: ``,
addrs: AbsMoveable, ConfigMoveable, and MoveableEndpoint These three types represent the three different address representations we need to represent different stages of analysis for "moved" blocks in the configuration. The goal here is to encapsulate all of the static address wrangling inside these types so that users of these types elsewhere would have to work pretty hard to use them incorrectly. In particular, the MovableEndpoint type intentionally fully encapsulates the weird relative addresses we use in configuration so that code elsewhere in Terraform can never end up holding an address of a type that suggests absolute when it's actually relative. That situation only occurs in the internals of MoveableEndpoint where we use not-really-absolute AbsMoveable address types to represent the not-yet-resolved relative addresses. This only takes care of the static address wrangling. There's lots of other rules for what makes a "moved" block valid which will need to be checked elsewhere because they require more context than just the content of the address itself.
2021-06-30 04:03:59 +02:00
},
{
InputFrom: `module.foo[0]`,
InputTo: `foo.bar`,
addrs: MoveEndpointInModule We previously built out addrs.UnifyMoveEndpoints with a different implementation strategy in mind, but that design turns out to not be viable because it forces us to move to AbsMoveable addresses too soon, before we've done the analysis required to identify chained and nested moves. Instead, UnifyMoveEndpoints will return a new type MoveEndpointInModule which conceptually represents a matching pattern which either matches or doesn't match a particular AbsMoveable. It does this by just binding the unified relative address from the MoveEndpoint to the module where it was declared, and thus allows us to distinguish between the part of the module path which applies to any instances of the given modules vs. the user-specified part which must identify particular module instances.
2021-07-12 21:23:10 +02:00
Module: RootModule,
WantFrom: ``, // Can't unify module instance with resource
WantTo: ``,
addrs: AbsMoveable, ConfigMoveable, and MoveableEndpoint These three types represent the three different address representations we need to represent different stages of analysis for "moved" blocks in the configuration. The goal here is to encapsulate all of the static address wrangling inside these types so that users of these types elsewhere would have to work pretty hard to use them incorrectly. In particular, the MovableEndpoint type intentionally fully encapsulates the weird relative addresses we use in configuration so that code elsewhere in Terraform can never end up holding an address of a type that suggests absolute when it's actually relative. That situation only occurs in the internals of MoveableEndpoint where we use not-really-absolute AbsMoveable address types to represent the not-yet-resolved relative addresses. This only takes care of the static address wrangling. There's lots of other rules for what makes a "moved" block valid which will need to be checked elsewhere because they require more context than just the content of the address itself.
2021-06-30 04:03:59 +02:00
},
{
InputFrom: `module.foo`,
InputTo: `foo.bar[0]`,
addrs: MoveEndpointInModule We previously built out addrs.UnifyMoveEndpoints with a different implementation strategy in mind, but that design turns out to not be viable because it forces us to move to AbsMoveable addresses too soon, before we've done the analysis required to identify chained and nested moves. Instead, UnifyMoveEndpoints will return a new type MoveEndpointInModule which conceptually represents a matching pattern which either matches or doesn't match a particular AbsMoveable. It does this by just binding the unified relative address from the MoveEndpoint to the module where it was declared, and thus allows us to distinguish between the part of the module path which applies to any instances of the given modules vs. the user-specified part which must identify particular module instances.
2021-07-12 21:23:10 +02:00
Module: RootModule,
WantFrom: ``, // Can't unify module call with resource instance
WantTo: ``,
addrs: AbsMoveable, ConfigMoveable, and MoveableEndpoint These three types represent the three different address representations we need to represent different stages of analysis for "moved" blocks in the configuration. The goal here is to encapsulate all of the static address wrangling inside these types so that users of these types elsewhere would have to work pretty hard to use them incorrectly. In particular, the MovableEndpoint type intentionally fully encapsulates the weird relative addresses we use in configuration so that code elsewhere in Terraform can never end up holding an address of a type that suggests absolute when it's actually relative. That situation only occurs in the internals of MoveableEndpoint where we use not-really-absolute AbsMoveable address types to represent the not-yet-resolved relative addresses. This only takes care of the static address wrangling. There's lots of other rules for what makes a "moved" block valid which will need to be checked elsewhere because they require more context than just the content of the address itself.
2021-06-30 04:03:59 +02:00
},
{
InputFrom: `module.foo[0]`,
InputTo: `foo.bar[0]`,
addrs: MoveEndpointInModule We previously built out addrs.UnifyMoveEndpoints with a different implementation strategy in mind, but that design turns out to not be viable because it forces us to move to AbsMoveable addresses too soon, before we've done the analysis required to identify chained and nested moves. Instead, UnifyMoveEndpoints will return a new type MoveEndpointInModule which conceptually represents a matching pattern which either matches or doesn't match a particular AbsMoveable. It does this by just binding the unified relative address from the MoveEndpoint to the module where it was declared, and thus allows us to distinguish between the part of the module path which applies to any instances of the given modules vs. the user-specified part which must identify particular module instances.
2021-07-12 21:23:10 +02:00
Module: RootModule,
WantFrom: ``, // Can't unify module instance with resource instance
WantTo: ``,
addrs: AbsMoveable, ConfigMoveable, and MoveableEndpoint These three types represent the three different address representations we need to represent different stages of analysis for "moved" blocks in the configuration. The goal here is to encapsulate all of the static address wrangling inside these types so that users of these types elsewhere would have to work pretty hard to use them incorrectly. In particular, the MovableEndpoint type intentionally fully encapsulates the weird relative addresses we use in configuration so that code elsewhere in Terraform can never end up holding an address of a type that suggests absolute when it's actually relative. That situation only occurs in the internals of MoveableEndpoint where we use not-really-absolute AbsMoveable address types to represent the not-yet-resolved relative addresses. This only takes care of the static address wrangling. There's lots of other rules for what makes a "moved" block valid which will need to be checked elsewhere because they require more context than just the content of the address itself.
2021-06-30 04:03:59 +02:00
},
}
for _, test := range tests {
t.Run(fmt.Sprintf("%s to %s in %s", test.InputFrom, test.InputTo, test.Module), func(t *testing.T) {
parseInput := func(input string) *MoveEndpoint {
t.Helper()
traversal, hclDiags := hclsyntax.ParseTraversalAbs([]byte(input), "", hcl.InitialPos)
if hclDiags.HasErrors() {
// We're not trying to test the HCL parser here, so any
// failures at this point are likely to be bugs in the
// test case itself.
t.Fatalf("syntax error: %s", hclDiags.Error())
}
moveEp, diags := ParseMoveEndpoint(traversal)
if diags.HasErrors() {
t.Fatalf("unexpected error: %s", diags.Err().Error())
}
return moveEp
}
fromEp := parseInput(test.InputFrom)
toEp := parseInput(test.InputTo)
gotFrom, gotTo := UnifyMoveEndpoints(test.Module, fromEp, toEp)
addrs: MoveEndpointInModule We previously built out addrs.UnifyMoveEndpoints with a different implementation strategy in mind, but that design turns out to not be viable because it forces us to move to AbsMoveable addresses too soon, before we've done the analysis required to identify chained and nested moves. Instead, UnifyMoveEndpoints will return a new type MoveEndpointInModule which conceptually represents a matching pattern which either matches or doesn't match a particular AbsMoveable. It does this by just binding the unified relative address from the MoveEndpoint to the module where it was declared, and thus allows us to distinguish between the part of the module path which applies to any instances of the given modules vs. the user-specified part which must identify particular module instances.
2021-07-12 21:23:10 +02:00
if got, want := gotFrom.String(), test.WantFrom; got != want {
t.Errorf("wrong 'from' result\ngot: %s\nwant: %s", got, want)
addrs: AbsMoveable, ConfigMoveable, and MoveableEndpoint These three types represent the three different address representations we need to represent different stages of analysis for "moved" blocks in the configuration. The goal here is to encapsulate all of the static address wrangling inside these types so that users of these types elsewhere would have to work pretty hard to use them incorrectly. In particular, the MovableEndpoint type intentionally fully encapsulates the weird relative addresses we use in configuration so that code elsewhere in Terraform can never end up holding an address of a type that suggests absolute when it's actually relative. That situation only occurs in the internals of MoveableEndpoint where we use not-really-absolute AbsMoveable address types to represent the not-yet-resolved relative addresses. This only takes care of the static address wrangling. There's lots of other rules for what makes a "moved" block valid which will need to be checked elsewhere because they require more context than just the content of the address itself.
2021-06-30 04:03:59 +02:00
}
addrs: MoveEndpointInModule We previously built out addrs.UnifyMoveEndpoints with a different implementation strategy in mind, but that design turns out to not be viable because it forces us to move to AbsMoveable addresses too soon, before we've done the analysis required to identify chained and nested moves. Instead, UnifyMoveEndpoints will return a new type MoveEndpointInModule which conceptually represents a matching pattern which either matches or doesn't match a particular AbsMoveable. It does this by just binding the unified relative address from the MoveEndpoint to the module where it was declared, and thus allows us to distinguish between the part of the module path which applies to any instances of the given modules vs. the user-specified part which must identify particular module instances.
2021-07-12 21:23:10 +02:00
if got, want := gotTo.String(), test.WantTo; got != want {
t.Errorf("wrong 'to' result\ngot: %s\nwant: %s", got, want)
addrs: AbsMoveable, ConfigMoveable, and MoveableEndpoint These three types represent the three different address representations we need to represent different stages of analysis for "moved" blocks in the configuration. The goal here is to encapsulate all of the static address wrangling inside these types so that users of these types elsewhere would have to work pretty hard to use them incorrectly. In particular, the MovableEndpoint type intentionally fully encapsulates the weird relative addresses we use in configuration so that code elsewhere in Terraform can never end up holding an address of a type that suggests absolute when it's actually relative. That situation only occurs in the internals of MoveableEndpoint where we use not-really-absolute AbsMoveable address types to represent the not-yet-resolved relative addresses. This only takes care of the static address wrangling. There's lots of other rules for what makes a "moved" block valid which will need to be checked elsewhere because they require more context than just the content of the address itself.
2021-06-30 04:03:59 +02:00
}
})
}
}
func TestMoveEndpointConfigMoveable(t *testing.T) {
tests := []struct {
Input string
Module Module
Want ConfigMoveable
}{
{
`foo.bar`,
RootModule,
ConfigResource{
Module: RootModule,
Resource: Resource{
Mode: ManagedResourceMode,
Type: "foo",
Name: "bar",
},
},
},
{
`foo.bar[0]`,
RootModule,
ConfigResource{
Module: RootModule,
Resource: Resource{
Mode: ManagedResourceMode,
Type: "foo",
Name: "bar",
},
},
},
{
`module.foo.bar.baz`,
RootModule,
ConfigResource{
Module: Module{"foo"},
Resource: Resource{
Mode: ManagedResourceMode,
Type: "bar",
Name: "baz",
},
},
},
{
`module.foo[0].bar.baz`,
RootModule,
ConfigResource{
Module: Module{"foo"},
Resource: Resource{
Mode: ManagedResourceMode,
Type: "bar",
Name: "baz",
},
},
},
{
`foo.bar`,
Module{"boop"},
ConfigResource{
Module: Module{"boop"},
Resource: Resource{
Mode: ManagedResourceMode,
Type: "foo",
Name: "bar",
},
},
},
{
`module.bloop.foo.bar`,
Module{"bleep"},
ConfigResource{
Module: Module{"bleep", "bloop"},
Resource: Resource{
Mode: ManagedResourceMode,
Type: "foo",
Name: "bar",
},
},
},
{
`module.foo.bar.baz`,
RootModule,
ConfigResource{
Module: Module{"foo"},
Resource: Resource{
Mode: ManagedResourceMode,
Type: "bar",
Name: "baz",
},
},
},
{
`module.foo`,
RootModule,
Module{"foo"},
},
{
`module.foo[0]`,
RootModule,
Module{"foo"},
},
{
`module.bloop`,
Module{"bleep"},
Module{"bleep", "bloop"},
},
{
`module.bloop[0]`,
Module{"bleep"},
Module{"bleep", "bloop"},
},
}
for _, test := range tests {
t.Run(fmt.Sprintf("%s in %s", test.Input, test.Module), func(t *testing.T) {
traversal, hclDiags := hclsyntax.ParseTraversalAbs([]byte(test.Input), "", hcl.InitialPos)
if hclDiags.HasErrors() {
// We're not trying to test the HCL parser here, so any
// failures at this point are likely to be bugs in the
// test case itself.
t.Fatalf("syntax error: %s", hclDiags.Error())
}
moveEp, diags := ParseMoveEndpoint(traversal)
if diags.HasErrors() {
t.Fatalf("unexpected error: %s", diags.Err().Error())
}
got := moveEp.ConfigMoveable(test.Module)
if diff := cmp.Diff(test.Want, got); diff != "" {
t.Errorf("wrong result\n%s", diff)
}
})
}
}