various: helpers for collecting necessary provider types
Since schemas are required to interpret provider, resource, and
provisioner attributes in configs, states, and plans, these helpers intend
to make it easier to gather up the the necessary provider types in order
to preload all of the needed schemas before beginning further processing.
Config.ProviderTypes returns directly the list of provider types, since
at this level further detail is not useful: we've not yet run the
provider allocation algorithm, and so the only thing we can reliably
extract here is provider types themselves.
State.ProviderAddrs and Plan.ProviderAddrs each return a list of
absolute provider addresses, which can then be turned into a list of
provider types using the new helper providers.AddressedTypesAbs.
Since we're already using configs.Config throughout core, this also
updates the terraform.LoadSchemas helper to use Config.ProviderTypes
to find the necessary providers, rather than implementing its own
discovery logic. states.State is not yet plumbed in, so we cannot yet
use State.ProviderAddrs to deal with the state but there's a TODO comment
to remind us to update that in a later commit when we swap out
terraform.State for states.State.
A later commit will probably refactor this further so that we can easily
obtain schema for the providers needed to interpret a plan too, but that
is deferred here because further work is required to make core work with
the new plan types first. At that point, terraform.LoadSchemas may become
providers.LoadSchemas with a different interface that just accepts lists
of provider and provisioner names that have been gathered by the caller
using these new helpers.
2018-06-22 02:39:27 +02:00
|
|
|
package configs
|
|
|
|
|
|
|
|
|
|
import (
|
|
|
|
|
"testing"
|
|
|
|
|
|
|
|
|
|
"github.com/go-test/deep"
|
2020-03-26 20:04:48 +01:00
|
|
|
"github.com/google/go-cmp/cmp"
|
2020-06-09 19:32:56 +02:00
|
|
|
"github.com/google/go-cmp/cmp/cmpopts"
|
|
|
|
|
"github.com/zclconf/go-cty/cty"
|
Initial steps towards AbsProviderConfig/LocalProviderConfig separation (#23978)
* Introduce "Local" terminology for non-absolute provider config addresses
In a future change AbsProviderConfig and LocalProviderConfig are going to
become two entirely distinct types, rather than Abs embedding Local as
written here. This naming change is in preparation for that subsequent
work, which will also include introducing a new "ProviderConfig" type
that is an interface that AbsProviderConfig and LocalProviderConfig both
implement.
This is intended to be largely just a naming change to get started, so
we can deal with all of the messy renaming. However, this did also require
a slight change in modeling where the Resource.DefaultProviderConfig
method has become Resource.DefaultProvider returning a Provider address
directly, because this method doesn't have enough information to construct
a true and accurate LocalProviderConfig -- it would need to refer to the
configuration to know what this module is calling the provider it has
selected.
In order to leave a trail to follow for subsequent work, all of the
changes here are intended to ensure that remaining work will become
obvious via compile-time errors when all of the following changes happen:
- The concept of "legacy" provider addresses is removed from the addrs
package, including removing addrs.NewLegacyProvider and
addrs.Provider.LegacyString.
- addrs.AbsProviderConfig stops having addrs.LocalProviderConfig embedded
in it and has an addrs.Provider and a string alias directly instead.
- The provider-schema-handling parts of Terraform core are updated to
work with addrs.Provider to identify providers, rather than legacy
strings.
In particular, there are still several codepaths here making legacy
provider address assumptions (in order to limit the scope of this change)
but I've made sure each one is doing something that relies on at least
one of the above changes not having been made yet.
* addrs: ProviderConfig interface
In a (very) few special situations in the main "terraform" package we need
to make runtime decisions about whether a provider config is absolute
or local.
We currently do that by exploiting the fact that AbsProviderConfig has
LocalProviderConfig nested inside of it and so in the local case we can
just ignore the wrapping AbsProviderConfig and use the embedded value.
In a future change we'll be moving away from that embedding and making
these two types distinct in order to represent that mapping between them
requires consulting a lookup table in the configuration, and so here we
introduce a new interface type ProviderConfig that can represent either
AbsProviderConfig or LocalProviderConfig decided dynamically at runtime.
This also includes the Config.ResolveAbsProviderAddr method that will
eventually be responsible for that local-to-absolute translation, so
that callers with access to the configuration can normalize to an
addrs.AbsProviderConfig given a non-nil addrs.ProviderConfig. That's
currently unused because existing callers are still relying on the
simplistic structural transform, but we'll switch them over in a later
commit.
* rename LocalType to LocalName
Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
2020-01-31 14:23:07 +01:00
|
|
|
|
2020-06-09 19:32:56 +02:00
|
|
|
version "github.com/hashicorp/go-version"
|
|
|
|
|
"github.com/hashicorp/hcl/v2/hclsyntax"
|
2020-03-26 20:04:48 +01:00
|
|
|
svchost "github.com/hashicorp/terraform-svchost"
|
2021-05-17 21:00:50 +02:00
|
|
|
"github.com/hashicorp/terraform/internal/addrs"
|
2020-03-26 20:04:48 +01:00
|
|
|
"github.com/hashicorp/terraform/internal/getproviders"
|
various: helpers for collecting necessary provider types
Since schemas are required to interpret provider, resource, and
provisioner attributes in configs, states, and plans, these helpers intend
to make it easier to gather up the the necessary provider types in order
to preload all of the needed schemas before beginning further processing.
Config.ProviderTypes returns directly the list of provider types, since
at this level further detail is not useful: we've not yet run the
provider allocation algorithm, and so the only thing we can reliably
extract here is provider types themselves.
State.ProviderAddrs and Plan.ProviderAddrs each return a list of
absolute provider addresses, which can then be turned into a list of
provider types using the new helper providers.AddressedTypesAbs.
Since we're already using configs.Config throughout core, this also
updates the terraform.LoadSchemas helper to use Config.ProviderTypes
to find the necessary providers, rather than implementing its own
discovery logic. states.State is not yet plumbed in, so we cannot yet
use State.ProviderAddrs to deal with the state but there's a TODO comment
to remind us to update that in a later commit when we swap out
terraform.State for states.State.
A later commit will probably refactor this further so that we can easily
obtain schema for the providers needed to interpret a plan too, but that
is deferred here because further work is required to make core work with
the new plan types first. At that point, terraform.LoadSchemas may become
providers.LoadSchemas with a different interface that just accepts lists
of provider and provisioner names that have been gathered by the caller
using these new helpers.
2018-06-22 02:39:27 +02:00
|
|
|
)
|
|
|
|
|
|
|
|
|
|
func TestConfigProviderTypes(t *testing.T) {
|
2020-03-23 14:50:35 +01:00
|
|
|
// nil cfg should return an empty map
|
|
|
|
|
got := NewEmptyConfig().ProviderTypes()
|
|
|
|
|
if len(got) != 0 {
|
|
|
|
|
t.Fatal("expected empty result from empty config")
|
|
|
|
|
}
|
|
|
|
|
|
2020-03-12 17:00:00 +01:00
|
|
|
cfg, diags := testModuleConfigFromFile("testdata/valid-files/providers-explicit-implied.tf")
|
various: helpers for collecting necessary provider types
Since schemas are required to interpret provider, resource, and
provisioner attributes in configs, states, and plans, these helpers intend
to make it easier to gather up the the necessary provider types in order
to preload all of the needed schemas before beginning further processing.
Config.ProviderTypes returns directly the list of provider types, since
at this level further detail is not useful: we've not yet run the
provider allocation algorithm, and so the only thing we can reliably
extract here is provider types themselves.
State.ProviderAddrs and Plan.ProviderAddrs each return a list of
absolute provider addresses, which can then be turned into a list of
provider types using the new helper providers.AddressedTypesAbs.
Since we're already using configs.Config throughout core, this also
updates the terraform.LoadSchemas helper to use Config.ProviderTypes
to find the necessary providers, rather than implementing its own
discovery logic. states.State is not yet plumbed in, so we cannot yet
use State.ProviderAddrs to deal with the state but there's a TODO comment
to remind us to update that in a later commit when we swap out
terraform.State for states.State.
A later commit will probably refactor this further so that we can easily
obtain schema for the providers needed to interpret a plan too, but that
is deferred here because further work is required to make core work with
the new plan types first. At that point, terraform.LoadSchemas may become
providers.LoadSchemas with a different interface that just accepts lists
of provider and provisioner names that have been gathered by the caller
using these new helpers.
2018-06-22 02:39:27 +02:00
|
|
|
if diags.HasErrors() {
|
|
|
|
|
t.Fatal(diags.Error())
|
|
|
|
|
}
|
|
|
|
|
|
2020-03-23 14:50:35 +01:00
|
|
|
got = cfg.ProviderTypes()
|
Initial steps towards AbsProviderConfig/LocalProviderConfig separation (#23978)
* Introduce "Local" terminology for non-absolute provider config addresses
In a future change AbsProviderConfig and LocalProviderConfig are going to
become two entirely distinct types, rather than Abs embedding Local as
written here. This naming change is in preparation for that subsequent
work, which will also include introducing a new "ProviderConfig" type
that is an interface that AbsProviderConfig and LocalProviderConfig both
implement.
This is intended to be largely just a naming change to get started, so
we can deal with all of the messy renaming. However, this did also require
a slight change in modeling where the Resource.DefaultProviderConfig
method has become Resource.DefaultProvider returning a Provider address
directly, because this method doesn't have enough information to construct
a true and accurate LocalProviderConfig -- it would need to refer to the
configuration to know what this module is calling the provider it has
selected.
In order to leave a trail to follow for subsequent work, all of the
changes here are intended to ensure that remaining work will become
obvious via compile-time errors when all of the following changes happen:
- The concept of "legacy" provider addresses is removed from the addrs
package, including removing addrs.NewLegacyProvider and
addrs.Provider.LegacyString.
- addrs.AbsProviderConfig stops having addrs.LocalProviderConfig embedded
in it and has an addrs.Provider and a string alias directly instead.
- The provider-schema-handling parts of Terraform core are updated to
work with addrs.Provider to identify providers, rather than legacy
strings.
In particular, there are still several codepaths here making legacy
provider address assumptions (in order to limit the scope of this change)
but I've made sure each one is doing something that relies on at least
one of the above changes not having been made yet.
* addrs: ProviderConfig interface
In a (very) few special situations in the main "terraform" package we need
to make runtime decisions about whether a provider config is absolute
or local.
We currently do that by exploiting the fact that AbsProviderConfig has
LocalProviderConfig nested inside of it and so in the local case we can
just ignore the wrapping AbsProviderConfig and use the embedded value.
In a future change we'll be moving away from that embedding and making
these two types distinct in order to represent that mapping between them
requires consulting a lookup table in the configuration, and so here we
introduce a new interface type ProviderConfig that can represent either
AbsProviderConfig or LocalProviderConfig decided dynamically at runtime.
This also includes the Config.ResolveAbsProviderAddr method that will
eventually be responsible for that local-to-absolute translation, so
that callers with access to the configuration can normalize to an
addrs.AbsProviderConfig given a non-nil addrs.ProviderConfig. That's
currently unused because existing callers are still relying on the
simplistic structural transform, but we'll switch them over in a later
commit.
* rename LocalType to LocalName
Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
2020-01-31 14:23:07 +01:00
|
|
|
want := []addrs.Provider{
|
2020-03-31 20:03:33 +02:00
|
|
|
addrs.NewDefaultProvider("aws"),
|
|
|
|
|
addrs.NewDefaultProvider("null"),
|
|
|
|
|
addrs.NewDefaultProvider("template"),
|
2020-09-21 22:32:50 +02:00
|
|
|
addrs.NewDefaultProvider("test"),
|
various: helpers for collecting necessary provider types
Since schemas are required to interpret provider, resource, and
provisioner attributes in configs, states, and plans, these helpers intend
to make it easier to gather up the the necessary provider types in order
to preload all of the needed schemas before beginning further processing.
Config.ProviderTypes returns directly the list of provider types, since
at this level further detail is not useful: we've not yet run the
provider allocation algorithm, and so the only thing we can reliably
extract here is provider types themselves.
State.ProviderAddrs and Plan.ProviderAddrs each return a list of
absolute provider addresses, which can then be turned into a list of
provider types using the new helper providers.AddressedTypesAbs.
Since we're already using configs.Config throughout core, this also
updates the terraform.LoadSchemas helper to use Config.ProviderTypes
to find the necessary providers, rather than implementing its own
discovery logic. states.State is not yet plumbed in, so we cannot yet
use State.ProviderAddrs to deal with the state but there's a TODO comment
to remind us to update that in a later commit when we swap out
terraform.State for states.State.
A later commit will probably refactor this further so that we can easily
obtain schema for the providers needed to interpret a plan too, but that
is deferred here because further work is required to make core work with
the new plan types first. At that point, terraform.LoadSchemas may become
providers.LoadSchemas with a different interface that just accepts lists
of provider and provisioner names that have been gathered by the caller
using these new helpers.
2018-06-22 02:39:27 +02:00
|
|
|
}
|
|
|
|
|
for _, problem := range deep.Equal(got, want) {
|
|
|
|
|
t.Error(problem)
|
|
|
|
|
}
|
|
|
|
|
}
|
Initial steps towards AbsProviderConfig/LocalProviderConfig separation (#23978)
* Introduce "Local" terminology for non-absolute provider config addresses
In a future change AbsProviderConfig and LocalProviderConfig are going to
become two entirely distinct types, rather than Abs embedding Local as
written here. This naming change is in preparation for that subsequent
work, which will also include introducing a new "ProviderConfig" type
that is an interface that AbsProviderConfig and LocalProviderConfig both
implement.
This is intended to be largely just a naming change to get started, so
we can deal with all of the messy renaming. However, this did also require
a slight change in modeling where the Resource.DefaultProviderConfig
method has become Resource.DefaultProvider returning a Provider address
directly, because this method doesn't have enough information to construct
a true and accurate LocalProviderConfig -- it would need to refer to the
configuration to know what this module is calling the provider it has
selected.
In order to leave a trail to follow for subsequent work, all of the
changes here are intended to ensure that remaining work will become
obvious via compile-time errors when all of the following changes happen:
- The concept of "legacy" provider addresses is removed from the addrs
package, including removing addrs.NewLegacyProvider and
addrs.Provider.LegacyString.
- addrs.AbsProviderConfig stops having addrs.LocalProviderConfig embedded
in it and has an addrs.Provider and a string alias directly instead.
- The provider-schema-handling parts of Terraform core are updated to
work with addrs.Provider to identify providers, rather than legacy
strings.
In particular, there are still several codepaths here making legacy
provider address assumptions (in order to limit the scope of this change)
but I've made sure each one is doing something that relies on at least
one of the above changes not having been made yet.
* addrs: ProviderConfig interface
In a (very) few special situations in the main "terraform" package we need
to make runtime decisions about whether a provider config is absolute
or local.
We currently do that by exploiting the fact that AbsProviderConfig has
LocalProviderConfig nested inside of it and so in the local case we can
just ignore the wrapping AbsProviderConfig and use the embedded value.
In a future change we'll be moving away from that embedding and making
these two types distinct in order to represent that mapping between them
requires consulting a lookup table in the configuration, and so here we
introduce a new interface type ProviderConfig that can represent either
AbsProviderConfig or LocalProviderConfig decided dynamically at runtime.
This also includes the Config.ResolveAbsProviderAddr method that will
eventually be responsible for that local-to-absolute translation, so
that callers with access to the configuration can normalize to an
addrs.AbsProviderConfig given a non-nil addrs.ProviderConfig. That's
currently unused because existing callers are still relying on the
simplistic structural transform, but we'll switch them over in a later
commit.
* rename LocalType to LocalName
Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
2020-01-31 14:23:07 +01:00
|
|
|
|
2020-03-12 17:00:00 +01:00
|
|
|
func TestConfigProviderTypes_nested(t *testing.T) {
|
|
|
|
|
// basic test with a nil config
|
|
|
|
|
c := NewEmptyConfig()
|
|
|
|
|
got := c.ProviderTypes()
|
|
|
|
|
if len(got) != 0 {
|
|
|
|
|
t.Fatalf("wrong result!\ngot: %#v\nwant: nil\n", got)
|
|
|
|
|
}
|
|
|
|
|
|
2020-03-16 19:36:16 +01:00
|
|
|
// config with two provider sources, and one implicit (default) provider
|
2020-03-12 17:00:00 +01:00
|
|
|
cfg, diags := testNestedModuleConfigFromDir(t, "testdata/valid-modules/nested-providers-fqns")
|
Initial steps towards AbsProviderConfig/LocalProviderConfig separation (#23978)
* Introduce "Local" terminology for non-absolute provider config addresses
In a future change AbsProviderConfig and LocalProviderConfig are going to
become two entirely distinct types, rather than Abs embedding Local as
written here. This naming change is in preparation for that subsequent
work, which will also include introducing a new "ProviderConfig" type
that is an interface that AbsProviderConfig and LocalProviderConfig both
implement.
This is intended to be largely just a naming change to get started, so
we can deal with all of the messy renaming. However, this did also require
a slight change in modeling where the Resource.DefaultProviderConfig
method has become Resource.DefaultProvider returning a Provider address
directly, because this method doesn't have enough information to construct
a true and accurate LocalProviderConfig -- it would need to refer to the
configuration to know what this module is calling the provider it has
selected.
In order to leave a trail to follow for subsequent work, all of the
changes here are intended to ensure that remaining work will become
obvious via compile-time errors when all of the following changes happen:
- The concept of "legacy" provider addresses is removed from the addrs
package, including removing addrs.NewLegacyProvider and
addrs.Provider.LegacyString.
- addrs.AbsProviderConfig stops having addrs.LocalProviderConfig embedded
in it and has an addrs.Provider and a string alias directly instead.
- The provider-schema-handling parts of Terraform core are updated to
work with addrs.Provider to identify providers, rather than legacy
strings.
In particular, there are still several codepaths here making legacy
provider address assumptions (in order to limit the scope of this change)
but I've made sure each one is doing something that relies on at least
one of the above changes not having been made yet.
* addrs: ProviderConfig interface
In a (very) few special situations in the main "terraform" package we need
to make runtime decisions about whether a provider config is absolute
or local.
We currently do that by exploiting the fact that AbsProviderConfig has
LocalProviderConfig nested inside of it and so in the local case we can
just ignore the wrapping AbsProviderConfig and use the embedded value.
In a future change we'll be moving away from that embedding and making
these two types distinct in order to represent that mapping between them
requires consulting a lookup table in the configuration, and so here we
introduce a new interface type ProviderConfig that can represent either
AbsProviderConfig or LocalProviderConfig decided dynamically at runtime.
This also includes the Config.ResolveAbsProviderAddr method that will
eventually be responsible for that local-to-absolute translation, so
that callers with access to the configuration can normalize to an
addrs.AbsProviderConfig given a non-nil addrs.ProviderConfig. That's
currently unused because existing callers are still relying on the
simplistic structural transform, but we'll switch them over in a later
commit.
* rename LocalType to LocalName
Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
2020-01-31 14:23:07 +01:00
|
|
|
if diags.HasErrors() {
|
|
|
|
|
t.Fatal(diags.Error())
|
|
|
|
|
}
|
|
|
|
|
|
2020-03-12 17:00:00 +01:00
|
|
|
got = cfg.ProviderTypes()
|
|
|
|
|
want := []addrs.Provider{
|
2021-05-27 20:09:28 +02:00
|
|
|
addrs.NewProvider(addrs.DefaultProviderRegistryHost, "bar", "test"),
|
|
|
|
|
addrs.NewProvider(addrs.DefaultProviderRegistryHost, "foo", "test"),
|
2020-03-31 20:03:33 +02:00
|
|
|
addrs.NewDefaultProvider("test"),
|
2020-03-12 17:00:00 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
for _, problem := range deep.Equal(got, want) {
|
|
|
|
|
t.Error(problem)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
func TestConfigResolveAbsProviderAddr(t *testing.T) {
|
|
|
|
|
cfg, diags := testModuleConfigFromDir("testdata/providers-explicit-fqn")
|
Initial steps towards AbsProviderConfig/LocalProviderConfig separation (#23978)
* Introduce "Local" terminology for non-absolute provider config addresses
In a future change AbsProviderConfig and LocalProviderConfig are going to
become two entirely distinct types, rather than Abs embedding Local as
written here. This naming change is in preparation for that subsequent
work, which will also include introducing a new "ProviderConfig" type
that is an interface that AbsProviderConfig and LocalProviderConfig both
implement.
This is intended to be largely just a naming change to get started, so
we can deal with all of the messy renaming. However, this did also require
a slight change in modeling where the Resource.DefaultProviderConfig
method has become Resource.DefaultProvider returning a Provider address
directly, because this method doesn't have enough information to construct
a true and accurate LocalProviderConfig -- it would need to refer to the
configuration to know what this module is calling the provider it has
selected.
In order to leave a trail to follow for subsequent work, all of the
changes here are intended to ensure that remaining work will become
obvious via compile-time errors when all of the following changes happen:
- The concept of "legacy" provider addresses is removed from the addrs
package, including removing addrs.NewLegacyProvider and
addrs.Provider.LegacyString.
- addrs.AbsProviderConfig stops having addrs.LocalProviderConfig embedded
in it and has an addrs.Provider and a string alias directly instead.
- The provider-schema-handling parts of Terraform core are updated to
work with addrs.Provider to identify providers, rather than legacy
strings.
In particular, there are still several codepaths here making legacy
provider address assumptions (in order to limit the scope of this change)
but I've made sure each one is doing something that relies on at least
one of the above changes not having been made yet.
* addrs: ProviderConfig interface
In a (very) few special situations in the main "terraform" package we need
to make runtime decisions about whether a provider config is absolute
or local.
We currently do that by exploiting the fact that AbsProviderConfig has
LocalProviderConfig nested inside of it and so in the local case we can
just ignore the wrapping AbsProviderConfig and use the embedded value.
In a future change we'll be moving away from that embedding and making
these two types distinct in order to represent that mapping between them
requires consulting a lookup table in the configuration, and so here we
introduce a new interface type ProviderConfig that can represent either
AbsProviderConfig or LocalProviderConfig decided dynamically at runtime.
This also includes the Config.ResolveAbsProviderAddr method that will
eventually be responsible for that local-to-absolute translation, so
that callers with access to the configuration can normalize to an
addrs.AbsProviderConfig given a non-nil addrs.ProviderConfig. That's
currently unused because existing callers are still relying on the
simplistic structural transform, but we'll switch them over in a later
commit.
* rename LocalType to LocalName
Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
2020-01-31 14:23:07 +01:00
|
|
|
if diags.HasErrors() {
|
|
|
|
|
t.Fatal(diags.Error())
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
t.Run("already absolute", func(t *testing.T) {
|
|
|
|
|
addr := addrs.AbsProviderConfig{
|
2020-03-09 22:11:57 +01:00
|
|
|
Module: addrs.RootModule,
|
2020-10-05 14:33:49 +02:00
|
|
|
Provider: addrs.NewDefaultProvider("test"),
|
2020-02-13 21:32:58 +01:00
|
|
|
Alias: "boop",
|
Initial steps towards AbsProviderConfig/LocalProviderConfig separation (#23978)
* Introduce "Local" terminology for non-absolute provider config addresses
In a future change AbsProviderConfig and LocalProviderConfig are going to
become two entirely distinct types, rather than Abs embedding Local as
written here. This naming change is in preparation for that subsequent
work, which will also include introducing a new "ProviderConfig" type
that is an interface that AbsProviderConfig and LocalProviderConfig both
implement.
This is intended to be largely just a naming change to get started, so
we can deal with all of the messy renaming. However, this did also require
a slight change in modeling where the Resource.DefaultProviderConfig
method has become Resource.DefaultProvider returning a Provider address
directly, because this method doesn't have enough information to construct
a true and accurate LocalProviderConfig -- it would need to refer to the
configuration to know what this module is calling the provider it has
selected.
In order to leave a trail to follow for subsequent work, all of the
changes here are intended to ensure that remaining work will become
obvious via compile-time errors when all of the following changes happen:
- The concept of "legacy" provider addresses is removed from the addrs
package, including removing addrs.NewLegacyProvider and
addrs.Provider.LegacyString.
- addrs.AbsProviderConfig stops having addrs.LocalProviderConfig embedded
in it and has an addrs.Provider and a string alias directly instead.
- The provider-schema-handling parts of Terraform core are updated to
work with addrs.Provider to identify providers, rather than legacy
strings.
In particular, there are still several codepaths here making legacy
provider address assumptions (in order to limit the scope of this change)
but I've made sure each one is doing something that relies on at least
one of the above changes not having been made yet.
* addrs: ProviderConfig interface
In a (very) few special situations in the main "terraform" package we need
to make runtime decisions about whether a provider config is absolute
or local.
We currently do that by exploiting the fact that AbsProviderConfig has
LocalProviderConfig nested inside of it and so in the local case we can
just ignore the wrapping AbsProviderConfig and use the embedded value.
In a future change we'll be moving away from that embedding and making
these two types distinct in order to represent that mapping between them
requires consulting a lookup table in the configuration, and so here we
introduce a new interface type ProviderConfig that can represent either
AbsProviderConfig or LocalProviderConfig decided dynamically at runtime.
This also includes the Config.ResolveAbsProviderAddr method that will
eventually be responsible for that local-to-absolute translation, so
that callers with access to the configuration can normalize to an
addrs.AbsProviderConfig given a non-nil addrs.ProviderConfig. That's
currently unused because existing callers are still relying on the
simplistic structural transform, but we'll switch them over in a later
commit.
* rename LocalType to LocalName
Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
2020-01-31 14:23:07 +01:00
|
|
|
}
|
2020-03-09 22:11:57 +01:00
|
|
|
got := cfg.ResolveAbsProviderAddr(addr, addrs.RootModule)
|
Initial steps towards AbsProviderConfig/LocalProviderConfig separation (#23978)
* Introduce "Local" terminology for non-absolute provider config addresses
In a future change AbsProviderConfig and LocalProviderConfig are going to
become two entirely distinct types, rather than Abs embedding Local as
written here. This naming change is in preparation for that subsequent
work, which will also include introducing a new "ProviderConfig" type
that is an interface that AbsProviderConfig and LocalProviderConfig both
implement.
This is intended to be largely just a naming change to get started, so
we can deal with all of the messy renaming. However, this did also require
a slight change in modeling where the Resource.DefaultProviderConfig
method has become Resource.DefaultProvider returning a Provider address
directly, because this method doesn't have enough information to construct
a true and accurate LocalProviderConfig -- it would need to refer to the
configuration to know what this module is calling the provider it has
selected.
In order to leave a trail to follow for subsequent work, all of the
changes here are intended to ensure that remaining work will become
obvious via compile-time errors when all of the following changes happen:
- The concept of "legacy" provider addresses is removed from the addrs
package, including removing addrs.NewLegacyProvider and
addrs.Provider.LegacyString.
- addrs.AbsProviderConfig stops having addrs.LocalProviderConfig embedded
in it and has an addrs.Provider and a string alias directly instead.
- The provider-schema-handling parts of Terraform core are updated to
work with addrs.Provider to identify providers, rather than legacy
strings.
In particular, there are still several codepaths here making legacy
provider address assumptions (in order to limit the scope of this change)
but I've made sure each one is doing something that relies on at least
one of the above changes not having been made yet.
* addrs: ProviderConfig interface
In a (very) few special situations in the main "terraform" package we need
to make runtime decisions about whether a provider config is absolute
or local.
We currently do that by exploiting the fact that AbsProviderConfig has
LocalProviderConfig nested inside of it and so in the local case we can
just ignore the wrapping AbsProviderConfig and use the embedded value.
In a future change we'll be moving away from that embedding and making
these two types distinct in order to represent that mapping between them
requires consulting a lookup table in the configuration, and so here we
introduce a new interface type ProviderConfig that can represent either
AbsProviderConfig or LocalProviderConfig decided dynamically at runtime.
This also includes the Config.ResolveAbsProviderAddr method that will
eventually be responsible for that local-to-absolute translation, so
that callers with access to the configuration can normalize to an
addrs.AbsProviderConfig given a non-nil addrs.ProviderConfig. That's
currently unused because existing callers are still relying on the
simplistic structural transform, but we'll switch them over in a later
commit.
* rename LocalType to LocalName
Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
2020-01-31 14:23:07 +01:00
|
|
|
if got, want := got.String(), addr.String(); got != want {
|
|
|
|
|
t.Errorf("wrong result\ngot: %s\nwant: %s", got, want)
|
|
|
|
|
}
|
|
|
|
|
})
|
|
|
|
|
t.Run("local, implied mapping", func(t *testing.T) {
|
|
|
|
|
addr := addrs.LocalProviderConfig{
|
|
|
|
|
LocalName: "implied",
|
|
|
|
|
Alias: "boop",
|
|
|
|
|
}
|
2020-03-09 22:11:57 +01:00
|
|
|
got := cfg.ResolveAbsProviderAddr(addr, addrs.RootModule)
|
Initial steps towards AbsProviderConfig/LocalProviderConfig separation (#23978)
* Introduce "Local" terminology for non-absolute provider config addresses
In a future change AbsProviderConfig and LocalProviderConfig are going to
become two entirely distinct types, rather than Abs embedding Local as
written here. This naming change is in preparation for that subsequent
work, which will also include introducing a new "ProviderConfig" type
that is an interface that AbsProviderConfig and LocalProviderConfig both
implement.
This is intended to be largely just a naming change to get started, so
we can deal with all of the messy renaming. However, this did also require
a slight change in modeling where the Resource.DefaultProviderConfig
method has become Resource.DefaultProvider returning a Provider address
directly, because this method doesn't have enough information to construct
a true and accurate LocalProviderConfig -- it would need to refer to the
configuration to know what this module is calling the provider it has
selected.
In order to leave a trail to follow for subsequent work, all of the
changes here are intended to ensure that remaining work will become
obvious via compile-time errors when all of the following changes happen:
- The concept of "legacy" provider addresses is removed from the addrs
package, including removing addrs.NewLegacyProvider and
addrs.Provider.LegacyString.
- addrs.AbsProviderConfig stops having addrs.LocalProviderConfig embedded
in it and has an addrs.Provider and a string alias directly instead.
- The provider-schema-handling parts of Terraform core are updated to
work with addrs.Provider to identify providers, rather than legacy
strings.
In particular, there are still several codepaths here making legacy
provider address assumptions (in order to limit the scope of this change)
but I've made sure each one is doing something that relies on at least
one of the above changes not having been made yet.
* addrs: ProviderConfig interface
In a (very) few special situations in the main "terraform" package we need
to make runtime decisions about whether a provider config is absolute
or local.
We currently do that by exploiting the fact that AbsProviderConfig has
LocalProviderConfig nested inside of it and so in the local case we can
just ignore the wrapping AbsProviderConfig and use the embedded value.
In a future change we'll be moving away from that embedding and making
these two types distinct in order to represent that mapping between them
requires consulting a lookup table in the configuration, and so here we
introduce a new interface type ProviderConfig that can represent either
AbsProviderConfig or LocalProviderConfig decided dynamically at runtime.
This also includes the Config.ResolveAbsProviderAddr method that will
eventually be responsible for that local-to-absolute translation, so
that callers with access to the configuration can normalize to an
addrs.AbsProviderConfig given a non-nil addrs.ProviderConfig. That's
currently unused because existing callers are still relying on the
simplistic structural transform, but we'll switch them over in a later
commit.
* rename LocalType to LocalName
Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
2020-01-31 14:23:07 +01:00
|
|
|
want := addrs.AbsProviderConfig{
|
2020-03-31 20:03:33 +02:00
|
|
|
Module: addrs.RootModule,
|
|
|
|
|
Provider: addrs.NewDefaultProvider("implied"),
|
2020-02-13 21:32:58 +01:00
|
|
|
Alias: "boop",
|
Initial steps towards AbsProviderConfig/LocalProviderConfig separation (#23978)
* Introduce "Local" terminology for non-absolute provider config addresses
In a future change AbsProviderConfig and LocalProviderConfig are going to
become two entirely distinct types, rather than Abs embedding Local as
written here. This naming change is in preparation for that subsequent
work, which will also include introducing a new "ProviderConfig" type
that is an interface that AbsProviderConfig and LocalProviderConfig both
implement.
This is intended to be largely just a naming change to get started, so
we can deal with all of the messy renaming. However, this did also require
a slight change in modeling where the Resource.DefaultProviderConfig
method has become Resource.DefaultProvider returning a Provider address
directly, because this method doesn't have enough information to construct
a true and accurate LocalProviderConfig -- it would need to refer to the
configuration to know what this module is calling the provider it has
selected.
In order to leave a trail to follow for subsequent work, all of the
changes here are intended to ensure that remaining work will become
obvious via compile-time errors when all of the following changes happen:
- The concept of "legacy" provider addresses is removed from the addrs
package, including removing addrs.NewLegacyProvider and
addrs.Provider.LegacyString.
- addrs.AbsProviderConfig stops having addrs.LocalProviderConfig embedded
in it and has an addrs.Provider and a string alias directly instead.
- The provider-schema-handling parts of Terraform core are updated to
work with addrs.Provider to identify providers, rather than legacy
strings.
In particular, there are still several codepaths here making legacy
provider address assumptions (in order to limit the scope of this change)
but I've made sure each one is doing something that relies on at least
one of the above changes not having been made yet.
* addrs: ProviderConfig interface
In a (very) few special situations in the main "terraform" package we need
to make runtime decisions about whether a provider config is absolute
or local.
We currently do that by exploiting the fact that AbsProviderConfig has
LocalProviderConfig nested inside of it and so in the local case we can
just ignore the wrapping AbsProviderConfig and use the embedded value.
In a future change we'll be moving away from that embedding and making
these two types distinct in order to represent that mapping between them
requires consulting a lookup table in the configuration, and so here we
introduce a new interface type ProviderConfig that can represent either
AbsProviderConfig or LocalProviderConfig decided dynamically at runtime.
This also includes the Config.ResolveAbsProviderAddr method that will
eventually be responsible for that local-to-absolute translation, so
that callers with access to the configuration can normalize to an
addrs.AbsProviderConfig given a non-nil addrs.ProviderConfig. That's
currently unused because existing callers are still relying on the
simplistic structural transform, but we'll switch them over in a later
commit.
* rename LocalType to LocalName
Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
2020-01-31 14:23:07 +01:00
|
|
|
}
|
|
|
|
|
if got, want := got.String(), want.String(); got != want {
|
|
|
|
|
t.Errorf("wrong result\ngot: %s\nwant: %s", got, want)
|
|
|
|
|
}
|
|
|
|
|
})
|
|
|
|
|
t.Run("local, explicit mapping", func(t *testing.T) {
|
|
|
|
|
addr := addrs.LocalProviderConfig{
|
2020-02-15 03:10:03 +01:00
|
|
|
LocalName: "foo-test", // this is explicitly set in the config
|
Initial steps towards AbsProviderConfig/LocalProviderConfig separation (#23978)
* Introduce "Local" terminology for non-absolute provider config addresses
In a future change AbsProviderConfig and LocalProviderConfig are going to
become two entirely distinct types, rather than Abs embedding Local as
written here. This naming change is in preparation for that subsequent
work, which will also include introducing a new "ProviderConfig" type
that is an interface that AbsProviderConfig and LocalProviderConfig both
implement.
This is intended to be largely just a naming change to get started, so
we can deal with all of the messy renaming. However, this did also require
a slight change in modeling where the Resource.DefaultProviderConfig
method has become Resource.DefaultProvider returning a Provider address
directly, because this method doesn't have enough information to construct
a true and accurate LocalProviderConfig -- it would need to refer to the
configuration to know what this module is calling the provider it has
selected.
In order to leave a trail to follow for subsequent work, all of the
changes here are intended to ensure that remaining work will become
obvious via compile-time errors when all of the following changes happen:
- The concept of "legacy" provider addresses is removed from the addrs
package, including removing addrs.NewLegacyProvider and
addrs.Provider.LegacyString.
- addrs.AbsProviderConfig stops having addrs.LocalProviderConfig embedded
in it and has an addrs.Provider and a string alias directly instead.
- The provider-schema-handling parts of Terraform core are updated to
work with addrs.Provider to identify providers, rather than legacy
strings.
In particular, there are still several codepaths here making legacy
provider address assumptions (in order to limit the scope of this change)
but I've made sure each one is doing something that relies on at least
one of the above changes not having been made yet.
* addrs: ProviderConfig interface
In a (very) few special situations in the main "terraform" package we need
to make runtime decisions about whether a provider config is absolute
or local.
We currently do that by exploiting the fact that AbsProviderConfig has
LocalProviderConfig nested inside of it and so in the local case we can
just ignore the wrapping AbsProviderConfig and use the embedded value.
In a future change we'll be moving away from that embedding and making
these two types distinct in order to represent that mapping between them
requires consulting a lookup table in the configuration, and so here we
introduce a new interface type ProviderConfig that can represent either
AbsProviderConfig or LocalProviderConfig decided dynamically at runtime.
This also includes the Config.ResolveAbsProviderAddr method that will
eventually be responsible for that local-to-absolute translation, so
that callers with access to the configuration can normalize to an
addrs.AbsProviderConfig given a non-nil addrs.ProviderConfig. That's
currently unused because existing callers are still relying on the
simplistic structural transform, but we'll switch them over in a later
commit.
* rename LocalType to LocalName
Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
2020-01-31 14:23:07 +01:00
|
|
|
Alias: "boop",
|
|
|
|
|
}
|
2020-03-09 22:11:57 +01:00
|
|
|
got := cfg.ResolveAbsProviderAddr(addr, addrs.RootModule)
|
Initial steps towards AbsProviderConfig/LocalProviderConfig separation (#23978)
* Introduce "Local" terminology for non-absolute provider config addresses
In a future change AbsProviderConfig and LocalProviderConfig are going to
become two entirely distinct types, rather than Abs embedding Local as
written here. This naming change is in preparation for that subsequent
work, which will also include introducing a new "ProviderConfig" type
that is an interface that AbsProviderConfig and LocalProviderConfig both
implement.
This is intended to be largely just a naming change to get started, so
we can deal with all of the messy renaming. However, this did also require
a slight change in modeling where the Resource.DefaultProviderConfig
method has become Resource.DefaultProvider returning a Provider address
directly, because this method doesn't have enough information to construct
a true and accurate LocalProviderConfig -- it would need to refer to the
configuration to know what this module is calling the provider it has
selected.
In order to leave a trail to follow for subsequent work, all of the
changes here are intended to ensure that remaining work will become
obvious via compile-time errors when all of the following changes happen:
- The concept of "legacy" provider addresses is removed from the addrs
package, including removing addrs.NewLegacyProvider and
addrs.Provider.LegacyString.
- addrs.AbsProviderConfig stops having addrs.LocalProviderConfig embedded
in it and has an addrs.Provider and a string alias directly instead.
- The provider-schema-handling parts of Terraform core are updated to
work with addrs.Provider to identify providers, rather than legacy
strings.
In particular, there are still several codepaths here making legacy
provider address assumptions (in order to limit the scope of this change)
but I've made sure each one is doing something that relies on at least
one of the above changes not having been made yet.
* addrs: ProviderConfig interface
In a (very) few special situations in the main "terraform" package we need
to make runtime decisions about whether a provider config is absolute
or local.
We currently do that by exploiting the fact that AbsProviderConfig has
LocalProviderConfig nested inside of it and so in the local case we can
just ignore the wrapping AbsProviderConfig and use the embedded value.
In a future change we'll be moving away from that embedding and making
these two types distinct in order to represent that mapping between them
requires consulting a lookup table in the configuration, and so here we
introduce a new interface type ProviderConfig that can represent either
AbsProviderConfig or LocalProviderConfig decided dynamically at runtime.
This also includes the Config.ResolveAbsProviderAddr method that will
eventually be responsible for that local-to-absolute translation, so
that callers with access to the configuration can normalize to an
addrs.AbsProviderConfig given a non-nil addrs.ProviderConfig. That's
currently unused because existing callers are still relying on the
simplistic structural transform, but we'll switch them over in a later
commit.
* rename LocalType to LocalName
Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
2020-01-31 14:23:07 +01:00
|
|
|
want := addrs.AbsProviderConfig{
|
2020-03-09 22:11:57 +01:00
|
|
|
Module: addrs.RootModule,
|
2021-05-27 20:09:28 +02:00
|
|
|
Provider: addrs.NewProvider(addrs.DefaultProviderRegistryHost, "foo", "test"),
|
2020-02-13 21:32:58 +01:00
|
|
|
Alias: "boop",
|
Initial steps towards AbsProviderConfig/LocalProviderConfig separation (#23978)
* Introduce "Local" terminology for non-absolute provider config addresses
In a future change AbsProviderConfig and LocalProviderConfig are going to
become two entirely distinct types, rather than Abs embedding Local as
written here. This naming change is in preparation for that subsequent
work, which will also include introducing a new "ProviderConfig" type
that is an interface that AbsProviderConfig and LocalProviderConfig both
implement.
This is intended to be largely just a naming change to get started, so
we can deal with all of the messy renaming. However, this did also require
a slight change in modeling where the Resource.DefaultProviderConfig
method has become Resource.DefaultProvider returning a Provider address
directly, because this method doesn't have enough information to construct
a true and accurate LocalProviderConfig -- it would need to refer to the
configuration to know what this module is calling the provider it has
selected.
In order to leave a trail to follow for subsequent work, all of the
changes here are intended to ensure that remaining work will become
obvious via compile-time errors when all of the following changes happen:
- The concept of "legacy" provider addresses is removed from the addrs
package, including removing addrs.NewLegacyProvider and
addrs.Provider.LegacyString.
- addrs.AbsProviderConfig stops having addrs.LocalProviderConfig embedded
in it and has an addrs.Provider and a string alias directly instead.
- The provider-schema-handling parts of Terraform core are updated to
work with addrs.Provider to identify providers, rather than legacy
strings.
In particular, there are still several codepaths here making legacy
provider address assumptions (in order to limit the scope of this change)
but I've made sure each one is doing something that relies on at least
one of the above changes not having been made yet.
* addrs: ProviderConfig interface
In a (very) few special situations in the main "terraform" package we need
to make runtime decisions about whether a provider config is absolute
or local.
We currently do that by exploiting the fact that AbsProviderConfig has
LocalProviderConfig nested inside of it and so in the local case we can
just ignore the wrapping AbsProviderConfig and use the embedded value.
In a future change we'll be moving away from that embedding and making
these two types distinct in order to represent that mapping between them
requires consulting a lookup table in the configuration, and so here we
introduce a new interface type ProviderConfig that can represent either
AbsProviderConfig or LocalProviderConfig decided dynamically at runtime.
This also includes the Config.ResolveAbsProviderAddr method that will
eventually be responsible for that local-to-absolute translation, so
that callers with access to the configuration can normalize to an
addrs.AbsProviderConfig given a non-nil addrs.ProviderConfig. That's
currently unused because existing callers are still relying on the
simplistic structural transform, but we'll switch them over in a later
commit.
* rename LocalType to LocalName
Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
2020-01-31 14:23:07 +01:00
|
|
|
}
|
|
|
|
|
if got, want := got.String(), want.String(); got != want {
|
|
|
|
|
t.Errorf("wrong result\ngot: %s\nwant: %s", got, want)
|
|
|
|
|
}
|
|
|
|
|
})
|
|
|
|
|
}
|
2020-03-12 17:00:00 +01:00
|
|
|
|
2020-03-26 20:04:48 +01:00
|
|
|
func TestConfigProviderRequirements(t *testing.T) {
|
|
|
|
|
cfg, diags := testNestedModuleConfigFromDir(t, "testdata/provider-reqs")
|
2020-09-08 14:19:00 +02:00
|
|
|
// TODO: Version Constraint Deprecation.
|
|
|
|
|
// Once we've removed the version argument from provider configuration
|
|
|
|
|
// blocks, this can go back to expected 0 diagnostics.
|
|
|
|
|
// assertNoDiagnostics(t, diags)
|
|
|
|
|
assertDiagnosticCount(t, diags, 1)
|
|
|
|
|
assertDiagnosticSummary(t, diags, "Version constraints inside provider configuration blocks are deprecated")
|
2020-03-26 20:04:48 +01:00
|
|
|
|
|
|
|
|
tlsProvider := addrs.NewProvider(
|
2021-05-27 20:09:28 +02:00
|
|
|
addrs.DefaultProviderRegistryHost,
|
2020-03-26 20:04:48 +01:00
|
|
|
"hashicorp", "tls",
|
|
|
|
|
)
|
|
|
|
|
happycloudProvider := addrs.NewProvider(
|
|
|
|
|
svchost.Hostname("tf.example.com"),
|
|
|
|
|
"awesomecorp", "happycloud",
|
|
|
|
|
)
|
2020-03-31 20:03:33 +02:00
|
|
|
nullProvider := addrs.NewDefaultProvider("null")
|
|
|
|
|
randomProvider := addrs.NewDefaultProvider("random")
|
|
|
|
|
impliedProvider := addrs.NewDefaultProvider("implied")
|
2020-04-02 01:11:15 +02:00
|
|
|
terraformProvider := addrs.NewBuiltInProvider("terraform")
|
2020-04-10 19:26:38 +02:00
|
|
|
configuredProvider := addrs.NewDefaultProvider("configured")
|
2020-06-22 18:13:35 +02:00
|
|
|
grandchildProvider := addrs.NewDefaultProvider("grandchild")
|
2020-03-26 20:04:48 +01:00
|
|
|
|
|
|
|
|
got, diags := cfg.ProviderRequirements()
|
|
|
|
|
assertNoDiagnostics(t, diags)
|
|
|
|
|
want := getproviders.Requirements{
|
|
|
|
|
// the nullProvider constraints from the two modules are merged
|
|
|
|
|
nullProvider: getproviders.MustParseVersionConstraints("~> 2.0.0, 2.0.1"),
|
|
|
|
|
randomProvider: getproviders.MustParseVersionConstraints("~> 1.2.0"),
|
|
|
|
|
tlsProvider: getproviders.MustParseVersionConstraints("~> 3.0"),
|
2020-04-10 19:26:38 +02:00
|
|
|
configuredProvider: getproviders.MustParseVersionConstraints("~> 1.4"),
|
2020-03-26 20:04:48 +01:00
|
|
|
impliedProvider: nil,
|
|
|
|
|
happycloudProvider: nil,
|
2020-04-02 01:11:15 +02:00
|
|
|
terraformProvider: nil,
|
2020-06-22 18:13:35 +02:00
|
|
|
grandchildProvider: nil,
|
2020-03-26 20:04:48 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if diff := cmp.Diff(want, got); diff != "" {
|
|
|
|
|
t.Errorf("wrong result\n%s", diff)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2021-02-05 20:01:58 +01:00
|
|
|
func TestConfigProviderRequirementsShallow(t *testing.T) {
|
|
|
|
|
cfg, diags := testNestedModuleConfigFromDir(t, "testdata/provider-reqs")
|
|
|
|
|
// TODO: Version Constraint Deprecation.
|
|
|
|
|
// Once we've removed the version argument from provider configuration
|
|
|
|
|
// blocks, this can go back to expected 0 diagnostics.
|
|
|
|
|
// assertNoDiagnostics(t, diags)
|
|
|
|
|
assertDiagnosticCount(t, diags, 1)
|
|
|
|
|
assertDiagnosticSummary(t, diags, "Version constraints inside provider configuration blocks are deprecated")
|
|
|
|
|
|
|
|
|
|
tlsProvider := addrs.NewProvider(
|
2021-05-27 20:09:28 +02:00
|
|
|
addrs.DefaultProviderRegistryHost,
|
2021-02-05 20:01:58 +01:00
|
|
|
"hashicorp", "tls",
|
|
|
|
|
)
|
|
|
|
|
nullProvider := addrs.NewDefaultProvider("null")
|
|
|
|
|
randomProvider := addrs.NewDefaultProvider("random")
|
|
|
|
|
impliedProvider := addrs.NewDefaultProvider("implied")
|
|
|
|
|
terraformProvider := addrs.NewBuiltInProvider("terraform")
|
|
|
|
|
configuredProvider := addrs.NewDefaultProvider("configured")
|
|
|
|
|
|
|
|
|
|
got, diags := cfg.ProviderRequirementsShallow()
|
|
|
|
|
assertNoDiagnostics(t, diags)
|
|
|
|
|
want := getproviders.Requirements{
|
|
|
|
|
// the nullProvider constraint is only from the root module
|
|
|
|
|
nullProvider: getproviders.MustParseVersionConstraints("~> 2.0.0"),
|
|
|
|
|
randomProvider: getproviders.MustParseVersionConstraints("~> 1.2.0"),
|
|
|
|
|
tlsProvider: getproviders.MustParseVersionConstraints("~> 3.0"),
|
|
|
|
|
configuredProvider: getproviders.MustParseVersionConstraints("~> 1.4"),
|
|
|
|
|
impliedProvider: nil,
|
|
|
|
|
terraformProvider: nil,
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if diff := cmp.Diff(want, got); diff != "" {
|
|
|
|
|
t.Errorf("wrong result\n%s", diff)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2020-06-09 19:32:56 +02:00
|
|
|
func TestConfigProviderRequirementsByModule(t *testing.T) {
|
|
|
|
|
cfg, diags := testNestedModuleConfigFromDir(t, "testdata/provider-reqs")
|
2020-09-08 14:19:00 +02:00
|
|
|
// TODO: Version Constraint Deprecation.
|
|
|
|
|
// Once we've removed the version argument from provider configuration
|
|
|
|
|
// blocks, this can go back to expected 0 diagnostics.
|
|
|
|
|
// assertNoDiagnostics(t, diags)
|
|
|
|
|
assertDiagnosticCount(t, diags, 1)
|
|
|
|
|
assertDiagnosticSummary(t, diags, "Version constraints inside provider configuration blocks are deprecated")
|
2020-06-09 19:32:56 +02:00
|
|
|
|
|
|
|
|
tlsProvider := addrs.NewProvider(
|
2021-05-27 20:09:28 +02:00
|
|
|
addrs.DefaultProviderRegistryHost,
|
2020-06-09 19:32:56 +02:00
|
|
|
"hashicorp", "tls",
|
|
|
|
|
)
|
|
|
|
|
happycloudProvider := addrs.NewProvider(
|
|
|
|
|
svchost.Hostname("tf.example.com"),
|
|
|
|
|
"awesomecorp", "happycloud",
|
|
|
|
|
)
|
|
|
|
|
nullProvider := addrs.NewDefaultProvider("null")
|
|
|
|
|
randomProvider := addrs.NewDefaultProvider("random")
|
|
|
|
|
impliedProvider := addrs.NewDefaultProvider("implied")
|
|
|
|
|
terraformProvider := addrs.NewBuiltInProvider("terraform")
|
|
|
|
|
configuredProvider := addrs.NewDefaultProvider("configured")
|
2020-06-22 18:13:35 +02:00
|
|
|
grandchildProvider := addrs.NewDefaultProvider("grandchild")
|
2020-06-09 19:32:56 +02:00
|
|
|
|
|
|
|
|
got, diags := cfg.ProviderRequirementsByModule()
|
|
|
|
|
assertNoDiagnostics(t, diags)
|
|
|
|
|
want := &ModuleRequirements{
|
2020-06-09 19:33:07 +02:00
|
|
|
Name: "",
|
Refactoring of module source addresses and module installation
It's been a long while since we gave close attention to the codepaths for
module source address parsing and external module package installation.
Due to their age, these codepaths often diverged from our modern practices
such as representing address types in the addrs package, and encapsulating
package installation details only in a particular location.
In particular, this refactor makes source address parsing a separate step
from module installation, which therefore makes the result of that parsing
available to other Terraform subsystems which work with the configuration
representation objects.
This also presented the opportunity to better encapsulate our use of
go-getter into a new package "getmodules" (echoing "getproviders"), which
is intended to be the only part of Terraform that directly interacts with
go-getter.
This is largely just a refactor of the existing functionality into a new
code organization, but there is one notable change in behavior here: the
source address parsing now happens during configuration loading rather
than module installation, which may cause errors about invalid addresses
to be returned in different situations than before. That counts as
backward compatible because we only promise to remain compatible with
configurations that are _valid_, which means that they can be initialized,
planned, and applied without any errors. This doesn't introduce any new
error cases, and instead just makes a pre-existing error case be detected
earlier.
Our module registry client is still using its own special module address
type from registry/regsrc for now, with a small shim from the new
addrs.ModuleSourceRegistry type. Hopefully in a later commit we'll also
rework the registry client to work with the new address type, but this
commit is already big enough as it is.
2021-05-28 04:24:59 +02:00
|
|
|
SourceAddr: nil,
|
2020-06-09 19:33:07 +02:00
|
|
|
SourceDir: "testdata/provider-reqs",
|
2020-06-09 19:32:56 +02:00
|
|
|
Requirements: getproviders.Requirements{
|
|
|
|
|
// Only the root module's version is present here
|
|
|
|
|
nullProvider: getproviders.MustParseVersionConstraints("~> 2.0.0"),
|
|
|
|
|
randomProvider: getproviders.MustParseVersionConstraints("~> 1.2.0"),
|
|
|
|
|
tlsProvider: getproviders.MustParseVersionConstraints("~> 3.0"),
|
|
|
|
|
configuredProvider: getproviders.MustParseVersionConstraints("~> 1.4"),
|
|
|
|
|
impliedProvider: nil,
|
|
|
|
|
terraformProvider: nil,
|
|
|
|
|
},
|
|
|
|
|
Children: map[string]*ModuleRequirements{
|
|
|
|
|
"kinder": {
|
2020-06-09 19:33:07 +02:00
|
|
|
Name: "kinder",
|
Refactoring of module source addresses and module installation
It's been a long while since we gave close attention to the codepaths for
module source address parsing and external module package installation.
Due to their age, these codepaths often diverged from our modern practices
such as representing address types in the addrs package, and encapsulating
package installation details only in a particular location.
In particular, this refactor makes source address parsing a separate step
from module installation, which therefore makes the result of that parsing
available to other Terraform subsystems which work with the configuration
representation objects.
This also presented the opportunity to better encapsulate our use of
go-getter into a new package "getmodules" (echoing "getproviders"), which
is intended to be the only part of Terraform that directly interacts with
go-getter.
This is largely just a refactor of the existing functionality into a new
code organization, but there is one notable change in behavior here: the
source address parsing now happens during configuration loading rather
than module installation, which may cause errors about invalid addresses
to be returned in different situations than before. That counts as
backward compatible because we only promise to remain compatible with
configurations that are _valid_, which means that they can be initialized,
planned, and applied without any errors. This doesn't introduce any new
error cases, and instead just makes a pre-existing error case be detected
earlier.
Our module registry client is still using its own special module address
type from registry/regsrc for now, with a small shim from the new
addrs.ModuleSourceRegistry type. Hopefully in a later commit we'll also
rework the registry client to work with the new address type, but this
commit is already big enough as it is.
2021-05-28 04:24:59 +02:00
|
|
|
SourceAddr: addrs.ModuleSourceLocal("./child"),
|
2020-06-09 19:33:07 +02:00
|
|
|
SourceDir: "testdata/provider-reqs/child",
|
2020-06-09 19:32:56 +02:00
|
|
|
Requirements: getproviders.Requirements{
|
|
|
|
|
nullProvider: getproviders.MustParseVersionConstraints("= 2.0.1"),
|
|
|
|
|
happycloudProvider: nil,
|
|
|
|
|
},
|
2020-06-22 18:13:35 +02:00
|
|
|
Children: map[string]*ModuleRequirements{
|
|
|
|
|
"nested": {
|
|
|
|
|
Name: "nested",
|
Refactoring of module source addresses and module installation
It's been a long while since we gave close attention to the codepaths for
module source address parsing and external module package installation.
Due to their age, these codepaths often diverged from our modern practices
such as representing address types in the addrs package, and encapsulating
package installation details only in a particular location.
In particular, this refactor makes source address parsing a separate step
from module installation, which therefore makes the result of that parsing
available to other Terraform subsystems which work with the configuration
representation objects.
This also presented the opportunity to better encapsulate our use of
go-getter into a new package "getmodules" (echoing "getproviders"), which
is intended to be the only part of Terraform that directly interacts with
go-getter.
This is largely just a refactor of the existing functionality into a new
code organization, but there is one notable change in behavior here: the
source address parsing now happens during configuration loading rather
than module installation, which may cause errors about invalid addresses
to be returned in different situations than before. That counts as
backward compatible because we only promise to remain compatible with
configurations that are _valid_, which means that they can be initialized,
planned, and applied without any errors. This doesn't introduce any new
error cases, and instead just makes a pre-existing error case be detected
earlier.
Our module registry client is still using its own special module address
type from registry/regsrc for now, with a small shim from the new
addrs.ModuleSourceRegistry type. Hopefully in a later commit we'll also
rework the registry client to work with the new address type, but this
commit is already big enough as it is.
2021-05-28 04:24:59 +02:00
|
|
|
SourceAddr: addrs.ModuleSourceLocal("./grandchild"),
|
2020-06-22 18:13:35 +02:00
|
|
|
SourceDir: "testdata/provider-reqs/child/grandchild",
|
|
|
|
|
Requirements: getproviders.Requirements{
|
|
|
|
|
grandchildProvider: nil,
|
|
|
|
|
},
|
|
|
|
|
Children: map[string]*ModuleRequirements{},
|
|
|
|
|
},
|
|
|
|
|
},
|
2020-06-09 19:32:56 +02:00
|
|
|
},
|
|
|
|
|
},
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ignore := cmpopts.IgnoreUnexported(version.Constraint{}, cty.Value{}, hclsyntax.Body{})
|
|
|
|
|
if diff := cmp.Diff(want, got, ignore); diff != "" {
|
|
|
|
|
t.Errorf("wrong result\n%s", diff)
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2020-03-31 20:03:33 +02:00
|
|
|
func TestConfigProviderForConfigAddr(t *testing.T) {
|
2020-03-12 17:00:00 +01:00
|
|
|
cfg, diags := testModuleConfigFromDir("testdata/valid-modules/providers-fqns")
|
|
|
|
|
assertNoDiagnostics(t, diags)
|
|
|
|
|
|
|
|
|
|
got := cfg.ProviderForConfigAddr(addrs.NewDefaultLocalProviderConfig("foo-test"))
|
2021-05-27 20:09:28 +02:00
|
|
|
want := addrs.NewProvider(addrs.DefaultProviderRegistryHost, "foo", "test")
|
2020-03-12 17:00:00 +01:00
|
|
|
if !got.Equals(want) {
|
|
|
|
|
t.Errorf("wrong result\ngot: %s\nwant: %s", got, want)
|
|
|
|
|
}
|
|
|
|
|
|
2020-03-31 20:03:33 +02:00
|
|
|
// now check a provider that isn't in the configuration. It should return a DefaultProvider.
|
2020-03-12 17:00:00 +01:00
|
|
|
got = cfg.ProviderForConfigAddr(addrs.NewDefaultLocalProviderConfig("bar-test"))
|
2020-03-31 20:03:33 +02:00
|
|
|
want = addrs.NewDefaultProvider("bar-test")
|
2020-03-12 17:00:00 +01:00
|
|
|
if !got.Equals(want) {
|
|
|
|
|
t.Errorf("wrong result\ngot: %s\nwant: %s", got, want)
|
|
|
|
|
}
|
|
|
|
|
}
|
2020-06-02 15:29:59 +02:00
|
|
|
|
|
|
|
|
func TestConfigAddProviderRequirements(t *testing.T) {
|
|
|
|
|
cfg, diags := testModuleConfigFromFile("testdata/valid-files/providers-explicit-implied.tf")
|
|
|
|
|
assertNoDiagnostics(t, diags)
|
|
|
|
|
|
|
|
|
|
reqs := getproviders.Requirements{
|
|
|
|
|
addrs.NewDefaultProvider("null"): nil,
|
|
|
|
|
}
|
2020-06-22 18:13:35 +02:00
|
|
|
diags = cfg.addProviderRequirements(reqs, true)
|
2020-06-02 15:29:59 +02:00
|
|
|
assertNoDiagnostics(t, diags)
|
|
|
|
|
}
|