ResiLien
/
terraform
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
terraform/internal/command/format/object_id_test.go

214 lines
5.1 KiB
Go
Raw Normal View History

command: Reinstate object ids in the UIHook progress logs We used to treat the "id" attribute of a resource as special and elevate it into its own struct field "ID" in the state, but the new state format and provider protocol treats it just as any other attribute. However, it's still useful to show the value of a single identifying attribute when there isn't room in the UI for showing all of the attributes, and so here we take a new strategy of considering "id" along with some other conventional names as special only in the UI layer. This new heuristic approach can be adjusted over time as new provider patterns emerge, but for now it covers some common conventions we've seen in real providers. With that said, since all existing providers made for Terraform versions prior to v0.12 were forced to set "id", we won't see any use of other attributes here until providers are updated to remove the placeholder ids they were generating in cases where an id was not actually relevant but was forced by the old protocol. At that point the UX should be improved by showing a more relevant attribute instead. We now also allow for the possibility of no id at all, since that is valid for resources that exist only within the Terraform state, like the ones from the "random" and "tls" providers.
2018-10-13 19:47:46 +02:00
package format
import (
"fmt"
"testing"
unmark object ID or Name for formatting
2021-08-16 22:42:09 +02:00
"github.com/hashicorp/terraform/internal/lang/marks"
command: Reinstate object ids in the UIHook progress logs We used to treat the "id" attribute of a resource as special and elevate it into its own struct field "ID" in the state, but the new state format and provider protocol treats it just as any other attribute. However, it's still useful to show the value of a single identifying attribute when there isn't room in the UI for showing all of the attributes, and so here we take a new strategy of considering "id" along with some other conventional names as special only in the UI layer. This new heuristic approach can be adjusted over time as new provider patterns emerge, but for now it covers some common conventions we've seen in real providers. With that said, since all existing providers made for Terraform versions prior to v0.12 were forced to set "id", we won't see any use of other attributes here until providers are updated to remove the placeholder ids they were generating in cases where an id was not actually relevant but was forced by the old protocol. At that point the UX should be improved by showing a more relevant attribute instead. We now also allow for the possibility of no id at all, since that is valid for resources that exist only within the Terraform state, like the ones from the "random" and "tls" providers.
2018-10-13 19:47:46 +02:00
"github.com/zclconf/go-cty/cty"
)
func TestObjectValueIDOrName(t *testing.T) {
Updates after running `make fmt` with Go v1.11.1
2018-10-17 23:05:57 +02:00
tests := []struct {
command: Reinstate object ids in the UIHook progress logs We used to treat the "id" attribute of a resource as special and elevate it into its own struct field "ID" in the state, but the new state format and provider protocol treats it just as any other attribute. However, it's still useful to show the value of a single identifying attribute when there isn't room in the UI for showing all of the attributes, and so here we take a new strategy of considering "id" along with some other conventional names as special only in the UI layer. This new heuristic approach can be adjusted over time as new provider patterns emerge, but for now it covers some common conventions we've seen in real providers. With that said, since all existing providers made for Terraform versions prior to v0.12 were forced to set "id", we won't see any use of other attributes here until providers are updated to remove the placeholder ids they were generating in cases where an id was not actually relevant but was forced by the old protocol. At that point the UX should be improved by showing a more relevant attribute instead. We now also allow for the possibility of no id at all, since that is valid for resources that exist only within the Terraform state, like the ones from the "random" and "tls" providers.
2018-10-13 19:47:46 +02:00
obj cty.Value
id [2]string
name [2]string
either [2]string
}{
{
cty.NullVal(cty.EmptyObject),
[...]string{"", ""},
[...]string{"", ""},
[...]string{"", ""},
},
{
cty.UnknownVal(cty.EmptyObject),
[...]string{"", ""},
[...]string{"", ""},
[...]string{"", ""},
},
{
cty.EmptyObjectVal,
[...]string{"", ""},
[...]string{"", ""},
[...]string{"", ""},
},
{
cty.ObjectVal(map[string]cty.Value{
Updates after running `make fmt` with Go v1.11.1
2018-10-17 23:05:57 +02:00
"id": cty.StringVal("foo-123"),
command: Reinstate object ids in the UIHook progress logs We used to treat the "id" attribute of a resource as special and elevate it into its own struct field "ID" in the state, but the new state format and provider protocol treats it just as any other attribute. However, it's still useful to show the value of a single identifying attribute when there isn't room in the UI for showing all of the attributes, and so here we take a new strategy of considering "id" along with some other conventional names as special only in the UI layer. This new heuristic approach can be adjusted over time as new provider patterns emerge, but for now it covers some common conventions we've seen in real providers. With that said, since all existing providers made for Terraform versions prior to v0.12 were forced to set "id", we won't see any use of other attributes here until providers are updated to remove the placeholder ids they were generating in cases where an id was not actually relevant but was forced by the old protocol. At that point the UX should be improved by showing a more relevant attribute instead. We now also allow for the possibility of no id at all, since that is valid for resources that exist only within the Terraform state, like the ones from the "random" and "tls" providers.
2018-10-13 19:47:46 +02:00
}),
[...]string{"id", "foo-123"},
[...]string{"", ""},
[...]string{"id", "foo-123"},
},
{
cty.ObjectVal(map[string]cty.Value{
"id": cty.StringVal("foo-123"),
"name": cty.StringVal("awesome-foo"),
}),
[...]string{"id", "foo-123"},
[...]string{"name", "awesome-foo"},
[...]string{"id", "foo-123"},
},
{
cty.ObjectVal(map[string]cty.Value{
"name": cty.StringVal("awesome-foo"),
}),
[...]string{"name", "awesome-foo"},
[...]string{"name", "awesome-foo"},
[...]string{"name", "awesome-foo"},
},
unmark object ID or Name for formatting
2021-08-16 22:42:09 +02:00
{
cty.ObjectVal(map[string]cty.Value{
"name": cty.StringVal("awesome-foo").Mark(marks.Sensitive),
}),
[...]string{"", ""},
[...]string{"", ""},
[...]string{"", ""},
},
command: Reinstate object ids in the UIHook progress logs We used to treat the "id" attribute of a resource as special and elevate it into its own struct field "ID" in the state, but the new state format and provider protocol treats it just as any other attribute. However, it's still useful to show the value of a single identifying attribute when there isn't room in the UI for showing all of the attributes, and so here we take a new strategy of considering "id" along with some other conventional names as special only in the UI layer. This new heuristic approach can be adjusted over time as new provider patterns emerge, but for now it covers some common conventions we've seen in real providers. With that said, since all existing providers made for Terraform versions prior to v0.12 were forced to set "id", we won't see any use of other attributes here until providers are updated to remove the placeholder ids they were generating in cases where an id was not actually relevant but was forced by the old protocol. At that point the UX should be improved by showing a more relevant attribute instead. We now also allow for the possibility of no id at all, since that is valid for resources that exist only within the Terraform state, like the ones from the "random" and "tls" providers.
2018-10-13 19:47:46 +02:00
{
cty.ObjectVal(map[string]cty.Value{
"name": cty.StringVal("awesome-foo"),
"tags": cty.MapVal(map[string]cty.Value{
"Name": cty.StringVal("My Awesome Foo"),
}),
}),
[...]string{"name", "awesome-foo"},
[...]string{"name", "awesome-foo"},
[...]string{"name", "awesome-foo"},
},
{
cty.ObjectVal(map[string]cty.Value{
"tags": cty.MapVal(map[string]cty.Value{
"Name": cty.StringVal("My Awesome Foo"),
"name": cty.StringVal("awesome-foo"),
}),
}),
[...]string{"", ""},
[...]string{"tags.name", "awesome-foo"},
[...]string{"tags.name", "awesome-foo"},
},
{
cty.ObjectVal(map[string]cty.Value{
"tags": cty.MapVal(map[string]cty.Value{
"Name": cty.StringVal("My Awesome Foo"),
}),
}),
[...]string{"", ""},
[...]string{"tags.Name", "My Awesome Foo"},
[...]string{"tags.Name", "My Awesome Foo"},
},
// The following are degenerate cases, included to make sure we don't
// crash when we encounter them. If you're here fixing a reported panic
// in this formatter, this is the place to add a new test case.
{
cty.ObjectVal(map[string]cty.Value{
Updates after running `make fmt` with Go v1.11.1
2018-10-17 23:05:57 +02:00
"id": cty.True,
command: Reinstate object ids in the UIHook progress logs We used to treat the "id" attribute of a resource as special and elevate it into its own struct field "ID" in the state, but the new state format and provider protocol treats it just as any other attribute. However, it's still useful to show the value of a single identifying attribute when there isn't room in the UI for showing all of the attributes, and so here we take a new strategy of considering "id" along with some other conventional names as special only in the UI layer. This new heuristic approach can be adjusted over time as new provider patterns emerge, but for now it covers some common conventions we've seen in real providers. With that said, since all existing providers made for Terraform versions prior to v0.12 were forced to set "id", we won't see any use of other attributes here until providers are updated to remove the placeholder ids they were generating in cases where an id was not actually relevant but was forced by the old protocol. At that point the UX should be improved by showing a more relevant attribute instead. We now also allow for the possibility of no id at all, since that is valid for resources that exist only within the Terraform state, like the ones from the "random" and "tls" providers.
2018-10-13 19:47:46 +02:00
}),
[...]string{"", ""},
[...]string{"", ""},
[...]string{"", ""},
},
{
cty.ObjectVal(map[string]cty.Value{
Updates after running `make fmt` with Go v1.11.1
2018-10-17 23:05:57 +02:00
"id": cty.NullVal(cty.String),
command: Reinstate object ids in the UIHook progress logs We used to treat the "id" attribute of a resource as special and elevate it into its own struct field "ID" in the state, but the new state format and provider protocol treats it just as any other attribute. However, it's still useful to show the value of a single identifying attribute when there isn't room in the UI for showing all of the attributes, and so here we take a new strategy of considering "id" along with some other conventional names as special only in the UI layer. This new heuristic approach can be adjusted over time as new provider patterns emerge, but for now it covers some common conventions we've seen in real providers. With that said, since all existing providers made for Terraform versions prior to v0.12 were forced to set "id", we won't see any use of other attributes here until providers are updated to remove the placeholder ids they were generating in cases where an id was not actually relevant but was forced by the old protocol. At that point the UX should be improved by showing a more relevant attribute instead. We now also allow for the possibility of no id at all, since that is valid for resources that exist only within the Terraform state, like the ones from the "random" and "tls" providers.
2018-10-13 19:47:46 +02:00
}),
[...]string{"", ""},
[...]string{"", ""},
[...]string{"", ""},
},
{
cty.ObjectVal(map[string]cty.Value{
Updates after running `make fmt` with Go v1.11.1
2018-10-17 23:05:57 +02:00
"id": cty.UnknownVal(cty.String),
command: Reinstate object ids in the UIHook progress logs We used to treat the "id" attribute of a resource as special and elevate it into its own struct field "ID" in the state, but the new state format and provider protocol treats it just as any other attribute. However, it's still useful to show the value of a single identifying attribute when there isn't room in the UI for showing all of the attributes, and so here we take a new strategy of considering "id" along with some other conventional names as special only in the UI layer. This new heuristic approach can be adjusted over time as new provider patterns emerge, but for now it covers some common conventions we've seen in real providers. With that said, since all existing providers made for Terraform versions prior to v0.12 were forced to set "id", we won't see any use of other attributes here until providers are updated to remove the placeholder ids they were generating in cases where an id was not actually relevant but was forced by the old protocol. At that point the UX should be improved by showing a more relevant attribute instead. We now also allow for the possibility of no id at all, since that is valid for resources that exist only within the Terraform state, like the ones from the "random" and "tls" providers.
2018-10-13 19:47:46 +02:00
}),
[...]string{"", ""},
[...]string{"", ""},
[...]string{"", ""},
},
{
cty.ObjectVal(map[string]cty.Value{
"tags": cty.StringVal("foo"),
}),
[...]string{"", ""},
[...]string{"", ""},
[...]string{"", ""},
},
{
cty.ObjectVal(map[string]cty.Value{
"tags": cty.NullVal(cty.Map(cty.String)),
}),
[...]string{"", ""},
[...]string{"", ""},
[...]string{"", ""},
},
{
cty.ObjectVal(map[string]cty.Value{
"tags": cty.UnknownVal(cty.Map(cty.String)),
}),
[...]string{"", ""},
[...]string{"", ""},
[...]string{"", ""},
},
{
cty.ObjectVal(map[string]cty.Value{
"tags": cty.MapVal(map[string]cty.Value{
"Name": cty.True,
}),
}),
[...]string{"", ""},
[...]string{"", ""},
[...]string{"", ""},
},
{
cty.ObjectVal(map[string]cty.Value{
"tags": cty.MapVal(map[string]cty.Value{
"Name": cty.UnknownVal(cty.String),
}),
}),
[...]string{"", ""},
[...]string{"", ""},
unmark object ID or Name for formatting
2021-08-16 22:42:09 +02:00
[...]string{"", ""},
},
{
cty.ObjectVal(map[string]cty.Value{
"tags": cty.MapVal(map[string]cty.Value{
"Name": cty.UnknownVal(cty.String).Mark(marks.Sensitive),
}),
}),
[...]string{"", ""},
[...]string{"", ""},
command: Reinstate object ids in the UIHook progress logs We used to treat the "id" attribute of a resource as special and elevate it into its own struct field "ID" in the state, but the new state format and provider protocol treats it just as any other attribute. However, it's still useful to show the value of a single identifying attribute when there isn't room in the UI for showing all of the attributes, and so here we take a new strategy of considering "id" along with some other conventional names as special only in the UI layer. This new heuristic approach can be adjusted over time as new provider patterns emerge, but for now it covers some common conventions we've seen in real providers. With that said, since all existing providers made for Terraform versions prior to v0.12 were forced to set "id", we won't see any use of other attributes here until providers are updated to remove the placeholder ids they were generating in cases where an id was not actually relevant but was forced by the old protocol. At that point the UX should be improved by showing a more relevant attribute instead. We now also allow for the possibility of no id at all, since that is valid for resources that exist only within the Terraform state, like the ones from the "random" and "tls" providers.
2018-10-13 19:47:46 +02:00
[...]string{"", ""},
},
{
cty.ObjectVal(map[string]cty.Value{
"tags": cty.MapVal(map[string]cty.Value{
"Name": cty.NullVal(cty.String),
}),
}),
[...]string{"", ""},
[...]string{"", ""},
[...]string{"", ""},
},
}
Updates after running `make fmt` with Go v1.11.1
2018-10-17 23:05:57 +02:00
command: Reinstate object ids in the UIHook progress logs We used to treat the "id" attribute of a resource as special and elevate it into its own struct field "ID" in the state, but the new state format and provider protocol treats it just as any other attribute. However, it's still useful to show the value of a single identifying attribute when there isn't room in the UI for showing all of the attributes, and so here we take a new strategy of considering "id" along with some other conventional names as special only in the UI layer. This new heuristic approach can be adjusted over time as new provider patterns emerge, but for now it covers some common conventions we've seen in real providers. With that said, since all existing providers made for Terraform versions prior to v0.12 were forced to set "id", we won't see any use of other attributes here until providers are updated to remove the placeholder ids they were generating in cases where an id was not actually relevant but was forced by the old protocol. At that point the UX should be improved by showing a more relevant attribute instead. We now also allow for the possibility of no id at all, since that is valid for resources that exist only within the Terraform state, like the ones from the "random" and "tls" providers.
2018-10-13 19:47:46 +02:00
for _, test := range tests {
Updates after running `make fmt` with Go v1.11.1
2018-10-17 23:05:57 +02:00
t.Run(fmt.Sprintf("%#v", test.obj), func(t *testing.T) {
command: Reinstate object ids in the UIHook progress logs We used to treat the "id" attribute of a resource as special and elevate it into its own struct field "ID" in the state, but the new state format and provider protocol treats it just as any other attribute. However, it's still useful to show the value of a single identifying attribute when there isn't room in the UI for showing all of the attributes, and so here we take a new strategy of considering "id" along with some other conventional names as special only in the UI layer. This new heuristic approach can be adjusted over time as new provider patterns emerge, but for now it covers some common conventions we've seen in real providers. With that said, since all existing providers made for Terraform versions prior to v0.12 were forced to set "id", we won't see any use of other attributes here until providers are updated to remove the placeholder ids they were generating in cases where an id was not actually relevant but was forced by the old protocol. At that point the UX should be improved by showing a more relevant attribute instead. We now also allow for the possibility of no id at all, since that is valid for resources that exist only within the Terraform state, like the ones from the "random" and "tls" providers.
2018-10-13 19:47:46 +02:00
obj := test.obj
gotIDKey, gotIDVal := ObjectValueID(obj)
gotNameKey, gotNameVal := ObjectValueName(obj)
gotEitherKey, gotEitherVal := ObjectValueIDOrName(obj)
if got, want := [...]string{gotIDKey, gotIDVal}, test.id; got != want {
t.Errorf("wrong ObjectValueID result\ngot: %#v\nwant: %#v", got, want)
}
if got, want := [...]string{gotNameKey, gotNameVal}, test.name; got != want {
t.Errorf("wrong ObjectValueName result\ngot: %#v\nwant: %#v", got, want)
}
if got, want := [...]string{gotEitherKey, gotEitherVal}, test.either; got != want {
t.Errorf("wrong ObjectValueIDOrName result\ngot: %#v\nwant: %#v", got, want)
}
})
}
}