IntenseWebs/opentofu
3
0
Fork 0
mirror of https://github.com/opentofu/opentofu.git synced 2024-12-30 10:47:14 -06:00
Code Issues Packages Projects Releases Wiki Activity
838ffafc18
opentofu/terraform/module_dependencies_test.go

266 lines
6.8 KiB
Go
Raw Normal View History

core: build a module dependency tree from config+state This new private function takes a configuration tree and a state structure and finds all of the explicit and implied provider dependencies represented, returning them as a moduledeps.Module tree structure. It annotates each dependency with a "reason", which is intended to be useful to a user trying to figure out where a particular dependency is coming from, though we don't yet have any UI to view this. Nothing calls this yet, but a subsequent commit will use the result of this to produce a constraint-conforming map of provider factories during context initialization.
2017-04-20 20:22:32 -05:00
package terraform
import (
"testing"
"github.com/davecgh/go-spew/spew"
"github.com/hashicorp/terraform/config/module"
"github.com/hashicorp/terraform/moduledeps"
"github.com/hashicorp/terraform/plugin/discovery"
)
func TestModuleTreeDependencies(t *testing.T) {
tests := map[string]struct {
ConfigDir string // directory name from test-fixtures dir
State *State
Want *moduledeps.Module
}{
"no config or state": {
"",
nil,
&moduledeps.Module{
Name: "root",
Providers: moduledeps.Providers{},
Children: nil,
},
},
"empty config no state": {
"empty",
nil,
&moduledeps.Module{
Name: "root",
Providers: moduledeps.Providers{},
Children: nil,
},
},
"explicit provider": {
"module-deps-explicit-provider",
nil,
&moduledeps.Module{
Name: "root",
Providers: moduledeps.Providers{
"foo": moduledeps.ProviderDependency{
Rename VersionSet to Constraints VersionSet is a wrapper around version.Contraints, so rename it it as such.
2017-05-03 16:31:46 -05:00
Constraints: discovery.ConstraintStr(">=1.0.0").MustParse(),
Reason: moduledeps.ProviderDependencyExplicit,
core: build a module dependency tree from config+state This new private function takes a configuration tree and a state structure and finds all of the explicit and implied provider dependencies represented, returning them as a moduledeps.Module tree structure. It annotates each dependency with a "reason", which is intended to be useful to a user trying to figure out where a particular dependency is coming from, though we don't yet have any UI to view this. Nothing calls this yet, but a subsequent commit will use the result of this to produce a constraint-conforming map of provider factories during context initialization.
2017-04-20 20:22:32 -05:00
},
"foo.bar": moduledeps.ProviderDependency{
Rename VersionSet to Constraints VersionSet is a wrapper around version.Contraints, so rename it it as such.
2017-05-03 16:31:46 -05:00
Constraints: discovery.ConstraintStr(">=2.0.0").MustParse(),
Reason: moduledeps.ProviderDependencyExplicit,
core: build a module dependency tree from config+state This new private function takes a configuration tree and a state structure and finds all of the explicit and implied provider dependencies represented, returning them as a moduledeps.Module tree structure. It annotates each dependency with a "reason", which is intended to be useful to a user trying to figure out where a particular dependency is coming from, though we don't yet have any UI to view this. Nothing calls this yet, but a subsequent commit will use the result of this to produce a constraint-conforming map of provider factories during context initialization.
2017-04-20 20:22:32 -05:00
},
},
Children: nil,
},
},
"explicit provider unconstrained": {
"module-deps-explicit-provider-unconstrained",
nil,
&moduledeps.Module{
Name: "root",
Providers: moduledeps.Providers{
"foo": moduledeps.ProviderDependency{
Rename VersionSet to Constraints VersionSet is a wrapper around version.Contraints, so rename it it as such.
2017-05-03 16:31:46 -05:00
Constraints: discovery.AllVersions,
Reason: moduledeps.ProviderDependencyExplicit,
core: build a module dependency tree from config+state This new private function takes a configuration tree and a state structure and finds all of the explicit and implied provider dependencies represented, returning them as a moduledeps.Module tree structure. It annotates each dependency with a "reason", which is intended to be useful to a user trying to figure out where a particular dependency is coming from, though we don't yet have any UI to view this. Nothing calls this yet, but a subsequent commit will use the result of this to produce a constraint-conforming map of provider factories during context initialization.
2017-04-20 20:22:32 -05:00
},
},
Children: nil,
},
},
"implicit provider": {
"module-deps-implicit-provider",
nil,
&moduledeps.Module{
Name: "root",
Providers: moduledeps.Providers{
"foo": moduledeps.ProviderDependency{
Rename VersionSet to Constraints VersionSet is a wrapper around version.Contraints, so rename it it as such.
2017-05-03 16:31:46 -05:00
Constraints: discovery.AllVersions,
use the inherited provider configs in the graph Use the configured providers directly, rather than looking for inherited provider configuration during graph evaluation. First remove the provider config cache, and the associated SetProviderConfig and ParentProviderConfig methods on the eval context. Every provider must be configured, so there's no need to look for configuration from other provider instances. The config.ProviderConfig struct now has a Scope field which stores the proper path for the interpolation scope. To get this metadata to the interpolator, we add an EvalInterpolatProvider node which can carry the ProviderConfig, and an InterpolateProvider context method to carry the ProviderConfig.Scope into the InterplationScope. Some of the tests could be adjusted to account for the new inheritance behavior, and some were simply no longer valid and will be removed. The remaining tests have questions on how they should work in practice. This mostly concerns orphaned modules where there is no longer a way to obtain a provider. In some cases we may require that a minimal provider config be present to handle the destroy process, but we need further testing. All disabled code was commented out in this commit to record any additional comments. The following commit will be a cleanup pass.
2017-10-13 09:11:10 -05:00
//Reason: moduledeps.ProviderDependencyImplicit,
Reason: moduledeps.ProviderDependencyExplicit,
core: build a module dependency tree from config+state This new private function takes a configuration tree and a state structure and finds all of the explicit and implied provider dependencies represented, returning them as a moduledeps.Module tree structure. It annotates each dependency with a "reason", which is intended to be useful to a user trying to figure out where a particular dependency is coming from, though we don't yet have any UI to view this. Nothing calls this yet, but a subsequent commit will use the result of this to produce a constraint-conforming map of provider factories during context initialization.
2017-04-20 20:22:32 -05:00
},
"foo.baz": moduledeps.ProviderDependency{
Rename VersionSet to Constraints VersionSet is a wrapper around version.Contraints, so rename it it as such.
2017-05-03 16:31:46 -05:00
Constraints: discovery.AllVersions,
Reason: moduledeps.ProviderDependencyImplicit,
core: build a module dependency tree from config+state This new private function takes a configuration tree and a state structure and finds all of the explicit and implied provider dependencies represented, returning them as a moduledeps.Module tree structure. It annotates each dependency with a "reason", which is intended to be useful to a user trying to figure out where a particular dependency is coming from, though we don't yet have any UI to view this. Nothing calls this yet, but a subsequent commit will use the result of this to produce a constraint-conforming map of provider factories during context initialization.
2017-04-20 20:22:32 -05:00
},
},
Children: nil,
},
},
"explicit provider with resource": {
"module-deps-explicit-provider-resource",
nil,
&moduledeps.Module{
Name: "root",
Providers: moduledeps.Providers{
"foo": moduledeps.ProviderDependency{
Rename VersionSet to Constraints VersionSet is a wrapper around version.Contraints, so rename it it as such.
2017-05-03 16:31:46 -05:00
Constraints: discovery.ConstraintStr(">=1.0.0").MustParse(),
Reason: moduledeps.ProviderDependencyExplicit,
core: build a module dependency tree from config+state This new private function takes a configuration tree and a state structure and finds all of the explicit and implied provider dependencies represented, returning them as a moduledeps.Module tree structure. It annotates each dependency with a "reason", which is intended to be useful to a user trying to figure out where a particular dependency is coming from, though we don't yet have any UI to view this. Nothing calls this yet, but a subsequent commit will use the result of this to produce a constraint-conforming map of provider factories during context initialization.
2017-04-20 20:22:32 -05:00
},
},
Children: nil,
},
},
"inheritance of providers": {
"module-deps-inherit-provider",
nil,
&moduledeps.Module{
Name: "root",
Providers: moduledeps.Providers{
"foo": moduledeps.ProviderDependency{
Rename VersionSet to Constraints VersionSet is a wrapper around version.Contraints, so rename it it as such.
2017-05-03 16:31:46 -05:00
Constraints: discovery.AllVersions,
Reason: moduledeps.ProviderDependencyExplicit,
core: build a module dependency tree from config+state This new private function takes a configuration tree and a state structure and finds all of the explicit and implied provider dependencies represented, returning them as a moduledeps.Module tree structure. It annotates each dependency with a "reason", which is intended to be useful to a user trying to figure out where a particular dependency is coming from, though we don't yet have any UI to view this. Nothing calls this yet, but a subsequent commit will use the result of this to produce a constraint-conforming map of provider factories during context initialization.
2017-04-20 20:22:32 -05:00
},
"bar": moduledeps.ProviderDependency{
Rename VersionSet to Constraints VersionSet is a wrapper around version.Contraints, so rename it it as such.
2017-05-03 16:31:46 -05:00
Constraints: discovery.AllVersions,
Reason: moduledeps.ProviderDependencyExplicit,
core: build a module dependency tree from config+state This new private function takes a configuration tree and a state structure and finds all of the explicit and implied provider dependencies represented, returning them as a moduledeps.Module tree structure. It annotates each dependency with a "reason", which is intended to be useful to a user trying to figure out where a particular dependency is coming from, though we don't yet have any UI to view this. Nothing calls this yet, but a subsequent commit will use the result of this to produce a constraint-conforming map of provider factories during context initialization.
2017-04-20 20:22:32 -05:00
},
},
Children: []*moduledeps.Module{
{
Name: "child",
Providers: moduledeps.Providers{
"foo": moduledeps.ProviderDependency{
Rename VersionSet to Constraints VersionSet is a wrapper around version.Contraints, so rename it it as such.
2017-05-03 16:31:46 -05:00
Constraints: discovery.AllVersions,
use the inherited provider configs in the graph Use the configured providers directly, rather than looking for inherited provider configuration during graph evaluation. First remove the provider config cache, and the associated SetProviderConfig and ParentProviderConfig methods on the eval context. Every provider must be configured, so there's no need to look for configuration from other provider instances. The config.ProviderConfig struct now has a Scope field which stores the proper path for the interpolation scope. To get this metadata to the interpolator, we add an EvalInterpolatProvider node which can carry the ProviderConfig, and an InterpolateProvider context method to carry the ProviderConfig.Scope into the InterplationScope. Some of the tests could be adjusted to account for the new inheritance behavior, and some were simply no longer valid and will be removed. The remaining tests have questions on how they should work in practice. This mostly concerns orphaned modules where there is no longer a way to obtain a provider. In some cases we may require that a minimal provider config be present to handle the destroy process, but we need further testing. All disabled code was commented out in this commit to record any additional comments. The following commit will be a cleanup pass.
2017-10-13 09:11:10 -05:00
//Reason: moduledeps.ProviderDependencyInherited,
Reason: moduledeps.ProviderDependencyExplicit,
core: build a module dependency tree from config+state This new private function takes a configuration tree and a state structure and finds all of the explicit and implied provider dependencies represented, returning them as a moduledeps.Module tree structure. It annotates each dependency with a "reason", which is intended to be useful to a user trying to figure out where a particular dependency is coming from, though we don't yet have any UI to view this. Nothing calls this yet, but a subsequent commit will use the result of this to produce a constraint-conforming map of provider factories during context initialization.
2017-04-20 20:22:32 -05:00
},
"baz": moduledeps.ProviderDependency{
Rename VersionSet to Constraints VersionSet is a wrapper around version.Contraints, so rename it it as such.
2017-05-03 16:31:46 -05:00
Constraints: discovery.AllVersions,
use the inherited provider configs in the graph Use the configured providers directly, rather than looking for inherited provider configuration during graph evaluation. First remove the provider config cache, and the associated SetProviderConfig and ParentProviderConfig methods on the eval context. Every provider must be configured, so there's no need to look for configuration from other provider instances. The config.ProviderConfig struct now has a Scope field which stores the proper path for the interpolation scope. To get this metadata to the interpolator, we add an EvalInterpolatProvider node which can carry the ProviderConfig, and an InterpolateProvider context method to carry the ProviderConfig.Scope into the InterplationScope. Some of the tests could be adjusted to account for the new inheritance behavior, and some were simply no longer valid and will be removed. The remaining tests have questions on how they should work in practice. This mostly concerns orphaned modules where there is no longer a way to obtain a provider. In some cases we may require that a minimal provider config be present to handle the destroy process, but we need further testing. All disabled code was commented out in this commit to record any additional comments. The following commit will be a cleanup pass.
2017-10-13 09:11:10 -05:00
//Reason: moduledeps.ProviderDependencyImplicit,
Reason: moduledeps.ProviderDependencyExplicit,
core: build a module dependency tree from config+state This new private function takes a configuration tree and a state structure and finds all of the explicit and implied provider dependencies represented, returning them as a moduledeps.Module tree structure. It annotates each dependency with a "reason", which is intended to be useful to a user trying to figure out where a particular dependency is coming from, though we don't yet have any UI to view this. Nothing calls this yet, but a subsequent commit will use the result of this to produce a constraint-conforming map of provider factories during context initialization.
2017-04-20 20:22:32 -05:00
},
},
Children: []*moduledeps.Module{
{
Name: "grandchild",
Providers: moduledeps.Providers{
"foo": moduledeps.ProviderDependency{
Rename VersionSet to Constraints VersionSet is a wrapper around version.Contraints, so rename it it as such.
2017-05-03 16:31:46 -05:00
Constraints: discovery.AllVersions,
Reason: moduledeps.ProviderDependencyExplicit,
core: build a module dependency tree from config+state This new private function takes a configuration tree and a state structure and finds all of the explicit and implied provider dependencies represented, returning them as a moduledeps.Module tree structure. It annotates each dependency with a "reason", which is intended to be useful to a user trying to figure out where a particular dependency is coming from, though we don't yet have any UI to view this. Nothing calls this yet, but a subsequent commit will use the result of this to produce a constraint-conforming map of provider factories during context initialization.
2017-04-20 20:22:32 -05:00
},
"bar": moduledeps.ProviderDependency{
Rename VersionSet to Constraints VersionSet is a wrapper around version.Contraints, so rename it it as such.
2017-05-03 16:31:46 -05:00
Constraints: discovery.AllVersions,
use the inherited provider configs in the graph Use the configured providers directly, rather than looking for inherited provider configuration during graph evaluation. First remove the provider config cache, and the associated SetProviderConfig and ParentProviderConfig methods on the eval context. Every provider must be configured, so there's no need to look for configuration from other provider instances. The config.ProviderConfig struct now has a Scope field which stores the proper path for the interpolation scope. To get this metadata to the interpolator, we add an EvalInterpolatProvider node which can carry the ProviderConfig, and an InterpolateProvider context method to carry the ProviderConfig.Scope into the InterplationScope. Some of the tests could be adjusted to account for the new inheritance behavior, and some were simply no longer valid and will be removed. The remaining tests have questions on how they should work in practice. This mostly concerns orphaned modules where there is no longer a way to obtain a provider. In some cases we may require that a minimal provider config be present to handle the destroy process, but we need further testing. All disabled code was commented out in this commit to record any additional comments. The following commit will be a cleanup pass.
2017-10-13 09:11:10 -05:00
//Reason: moduledeps.ProviderDependencyInherited,
Reason: moduledeps.ProviderDependencyExplicit,
core: build a module dependency tree from config+state This new private function takes a configuration tree and a state structure and finds all of the explicit and implied provider dependencies represented, returning them as a moduledeps.Module tree structure. It annotates each dependency with a "reason", which is intended to be useful to a user trying to figure out where a particular dependency is coming from, though we don't yet have any UI to view this. Nothing calls this yet, but a subsequent commit will use the result of this to produce a constraint-conforming map of provider factories during context initialization.
2017-04-20 20:22:32 -05:00
},
},
},
},
},
},
},
},
"provider from state": {
"empty",
&State{
Modules: []*ModuleState{
{
Path: []string{"root"},
Resources: map[string]*ResourceState{
"foo_bar.baz": {
Type: "foo_bar",
Provider: "",
},
},
},
},
},
&moduledeps.Module{
Name: "root",
Providers: moduledeps.Providers{
"foo": moduledeps.ProviderDependency{
Rename VersionSet to Constraints VersionSet is a wrapper around version.Contraints, so rename it it as such.
2017-05-03 16:31:46 -05:00
Constraints: discovery.AllVersions,
Reason: moduledeps.ProviderDependencyFromState,
core: build a module dependency tree from config+state This new private function takes a configuration tree and a state structure and finds all of the explicit and implied provider dependencies represented, returning them as a moduledeps.Module tree structure. It annotates each dependency with a "reason", which is intended to be useful to a user trying to figure out where a particular dependency is coming from, though we don't yet have any UI to view this. Nothing calls this yet, but a subsequent commit will use the result of this to produce a constraint-conforming map of provider factories during context initialization.
2017-04-20 20:22:32 -05:00
},
},
Children: nil,
},
},
"providers in both config and state": {
"module-deps-explicit-provider",
&State{
Modules: []*ModuleState{
{
Path: []string{"root"},
Resources: map[string]*ResourceState{
"foo_bar.test1": {
Type: "foo_bar",
Provider: "",
},
"foo_bar.test2": {
Type: "foo_bar",
Provider: "foo.bar",
},
"baz_bar.test": {
Type: "baz_bar",
Provider: "",
},
},
},
// note that we've skipped root.child intentionally here,
// to verify that we'll infer it based on the following
// module rather than crashing.
{
Path: []string{"root", "child", "grandchild"},
Resources: map[string]*ResourceState{
"banana_skin.test": {
Type: "banana_skin",
Provider: "",
},
},
},
},
},
&moduledeps.Module{
Name: "root",
Providers: moduledeps.Providers{
"foo": moduledeps.ProviderDependency{
Rename VersionSet to Constraints VersionSet is a wrapper around version.Contraints, so rename it it as such.
2017-05-03 16:31:46 -05:00
Constraints: discovery.ConstraintStr(">=1.0.0").MustParse(),
Reason: moduledeps.ProviderDependencyExplicit,
core: build a module dependency tree from config+state This new private function takes a configuration tree and a state structure and finds all of the explicit and implied provider dependencies represented, returning them as a moduledeps.Module tree structure. It annotates each dependency with a "reason", which is intended to be useful to a user trying to figure out where a particular dependency is coming from, though we don't yet have any UI to view this. Nothing calls this yet, but a subsequent commit will use the result of this to produce a constraint-conforming map of provider factories during context initialization.
2017-04-20 20:22:32 -05:00
},
"foo.bar": moduledeps.ProviderDependency{
Rename VersionSet to Constraints VersionSet is a wrapper around version.Contraints, so rename it it as such.
2017-05-03 16:31:46 -05:00
Constraints: discovery.ConstraintStr(">=2.0.0").MustParse(),
Reason: moduledeps.ProviderDependencyExplicit,
core: build a module dependency tree from config+state This new private function takes a configuration tree and a state structure and finds all of the explicit and implied provider dependencies represented, returning them as a moduledeps.Module tree structure. It annotates each dependency with a "reason", which is intended to be useful to a user trying to figure out where a particular dependency is coming from, though we don't yet have any UI to view this. Nothing calls this yet, but a subsequent commit will use the result of this to produce a constraint-conforming map of provider factories during context initialization.
2017-04-20 20:22:32 -05:00
},
"baz": moduledeps.ProviderDependency{
Rename VersionSet to Constraints VersionSet is a wrapper around version.Contraints, so rename it it as such.
2017-05-03 16:31:46 -05:00
Constraints: discovery.AllVersions,
Reason: moduledeps.ProviderDependencyFromState,
core: build a module dependency tree from config+state This new private function takes a configuration tree and a state structure and finds all of the explicit and implied provider dependencies represented, returning them as a moduledeps.Module tree structure. It annotates each dependency with a "reason", which is intended to be useful to a user trying to figure out where a particular dependency is coming from, though we don't yet have any UI to view this. Nothing calls this yet, but a subsequent commit will use the result of this to produce a constraint-conforming map of provider factories during context initialization.
2017-04-20 20:22:32 -05:00
},
},
Children: []*moduledeps.Module{
{
Name: "child",
Children: []*moduledeps.Module{
{
Name: "grandchild",
Providers: moduledeps.Providers{
"banana": moduledeps.ProviderDependency{
Rename VersionSet to Constraints VersionSet is a wrapper around version.Contraints, so rename it it as such.
2017-05-03 16:31:46 -05:00
Constraints: discovery.AllVersions,
Reason: moduledeps.ProviderDependencyFromState,
core: build a module dependency tree from config+state This new private function takes a configuration tree and a state structure and finds all of the explicit and implied provider dependencies represented, returning them as a moduledeps.Module tree structure. It annotates each dependency with a "reason", which is intended to be useful to a user trying to figure out where a particular dependency is coming from, though we don't yet have any UI to view this. Nothing calls this yet, but a subsequent commit will use the result of this to produce a constraint-conforming map of provider factories during context initialization.
2017-04-20 20:22:32 -05:00
},
},
},
},
},
},
},
},
}
for name, test := range tests {
t.Run(name, func(t *testing.T) {
var root *module.Tree
if test.ConfigDir != "" {
root = testModule(t, test.ConfigDir)
}
core: expose terraform.ModuleTreeDependencies as a public function This is a generally-useful utility for computing dependency trees, so no reason to restrict it to just the terraform package.
2017-04-25 18:49:49 -05:00
got := ModuleTreeDependencies(root, test.State)
core: build a module dependency tree from config+state This new private function takes a configuration tree and a state structure and finds all of the explicit and implied provider dependencies represented, returning them as a moduledeps.Module tree structure. It annotates each dependency with a "reason", which is intended to be useful to a user trying to figure out where a particular dependency is coming from, though we don't yet have any UI to view this. Nothing calls this yet, but a subsequent commit will use the result of this to produce a constraint-conforming map of provider factories during context initialization.
2017-04-20 20:22:32 -05:00
if !got.Equal(test.Want) {
t.Errorf(
"wrong dependency tree\ngot: %s\nwant: %s",
spew.Sdump(got),
spew.Sdump(test.Want),
)
}
})
}
}
Reference in New Issue Copy Permalink