2019-01-09 03:39:14 +01:00
|
|
|
package initwd
|
|
|
|
|
|
|
|
import (
|
|
|
|
"testing"
|
|
|
|
|
2021-05-17 21:17:09 +02:00
|
|
|
"github.com/hashicorp/terraform/internal/configs"
|
|
|
|
"github.com/hashicorp/terraform/internal/configs/configload"
|
2021-05-17 18:45:36 +02:00
|
|
|
"github.com/hashicorp/terraform/internal/registry"
|
2021-05-17 19:11:06 +02:00
|
|
|
"github.com/hashicorp/terraform/internal/tfdiags"
|
2019-01-09 03:39:14 +01:00
|
|
|
)
|
|
|
|
|
|
|
|
// LoadConfigForTests is a convenience wrapper around configload.NewLoaderForTests,
|
|
|
|
// ModuleInstaller.InstallModules and configload.Loader.LoadConfig that allows
|
|
|
|
// a test configuration to be loaded in a single step.
|
|
|
|
//
|
|
|
|
// If module installation fails, t.Fatal (or similar) is called to halt
|
|
|
|
// execution of the test, under the assumption that installation failures are
|
|
|
|
// not expected. If installation failures _are_ expected then use
|
|
|
|
// NewLoaderForTests and work with the loader object directly. If module
|
|
|
|
// installation succeeds but generates warnings, these warnings are discarded.
|
|
|
|
//
|
|
|
|
// If installation succeeds but errors are detected during loading then a
|
|
|
|
// possibly-incomplete config is returned along with error diagnostics. The
|
|
|
|
// test run is not aborted in this case, so that the caller can make assertions
|
|
|
|
// against the returned diagnostics.
|
|
|
|
//
|
|
|
|
// As with NewLoaderForTests, a cleanup function is returned which must be
|
|
|
|
// called before the test completes in order to remove the temporary
|
|
|
|
// modules directory.
|
|
|
|
func LoadConfigForTests(t *testing.T, rootDir string) (*configs.Config, *configload.Loader, func(), tfdiags.Diagnostics) {
|
|
|
|
t.Helper()
|
|
|
|
|
|
|
|
var diags tfdiags.Diagnostics
|
|
|
|
|
|
|
|
loader, cleanup := configload.NewLoaderForTests(t)
|
|
|
|
inst := NewModuleInstaller(loader.ModulesDir(), registry.NewClient(nil, nil))
|
|
|
|
|
command: "terraform init" can partially initialize for 0.12upgrade
There are a few constructs from 0.11 and prior that cause 0.12 parsing to
fail altogether, which previously created a chicken/egg problem because
we need to install the providers in order to run "terraform 0.12upgrade"
and thus fix the problem.
This changes "terraform init" to use the new "early configuration" loader
for module and provider installation. This is built on the more permissive
parser in the terraform-config-inspect package, and so it allows us to
read out the top-level blocks from the configuration while accepting
legacy HCL syntax.
In the long run this will let us do version compatibility detection before
attempting a "real" config load, giving us better error messages for any
future syntax additions, but in the short term the key thing is that it
allows us to install the dependencies even if the configuration isn't
fully valid.
Because backend init still requires full configuration, this introduces a
new mode of terraform init where it detects heuristically if it seems like
we need to do a configuration upgrade and does a partial init if so,
before finally directing the user to run "terraform 0.12upgrade" before
running any other commands.
The heuristic here is based on two assumptions:
- If the "early" loader finds no errors but the normal loader does, the
configuration is likely to be valid for Terraform 0.11 but not 0.12.
- If there's already a version constraint in the configuration that
excludes Terraform versions prior to v0.12 then the configuration is
probably _already_ upgraded and so it's just a normal syntax error,
even if the early loader didn't detect it.
Once the upgrade process is removed in 0.13.0 (users will be required to
go stepwise 0.11 -> 0.12 -> 0.13 to upgrade after that), some of this can
be simplified to remove that special mode, but the idea of doing the
dependency version checks against the liberal parser will remain valuable
to increase our chances of reporting version-based incompatibilities
rather than syntax errors as we add new features in future.
2019-01-14 20:11:00 +01:00
|
|
|
_, moreDiags := inst.InstallModules(rootDir, true, ModuleInstallHooksImpl{})
|
2019-01-09 03:39:14 +01:00
|
|
|
diags = diags.Append(moreDiags)
|
|
|
|
if diags.HasErrors() {
|
|
|
|
cleanup()
|
|
|
|
t.Fatal(diags.Err())
|
|
|
|
return nil, nil, func() {}, diags
|
|
|
|
}
|
|
|
|
|
command: "terraform init" can partially initialize for 0.12upgrade
There are a few constructs from 0.11 and prior that cause 0.12 parsing to
fail altogether, which previously created a chicken/egg problem because
we need to install the providers in order to run "terraform 0.12upgrade"
and thus fix the problem.
This changes "terraform init" to use the new "early configuration" loader
for module and provider installation. This is built on the more permissive
parser in the terraform-config-inspect package, and so it allows us to
read out the top-level blocks from the configuration while accepting
legacy HCL syntax.
In the long run this will let us do version compatibility detection before
attempting a "real" config load, giving us better error messages for any
future syntax additions, but in the short term the key thing is that it
allows us to install the dependencies even if the configuration isn't
fully valid.
Because backend init still requires full configuration, this introduces a
new mode of terraform init where it detects heuristically if it seems like
we need to do a configuration upgrade and does a partial init if so,
before finally directing the user to run "terraform 0.12upgrade" before
running any other commands.
The heuristic here is based on two assumptions:
- If the "early" loader finds no errors but the normal loader does, the
configuration is likely to be valid for Terraform 0.11 but not 0.12.
- If there's already a version constraint in the configuration that
excludes Terraform versions prior to v0.12 then the configuration is
probably _already_ upgraded and so it's just a normal syntax error,
even if the early loader didn't detect it.
Once the upgrade process is removed in 0.13.0 (users will be required to
go stepwise 0.11 -> 0.12 -> 0.13 to upgrade after that), some of this can
be simplified to remove that special mode, but the idea of doing the
dependency version checks against the liberal parser will remain valuable
to increase our chances of reporting version-based incompatibilities
rather than syntax errors as we add new features in future.
2019-01-14 20:11:00 +01:00
|
|
|
// Since module installer has modified the module manifest on disk, we need
|
|
|
|
// to refresh the cache of it in the loader.
|
|
|
|
if err := loader.RefreshModules(); err != nil {
|
|
|
|
t.Fatalf("failed to refresh modules after installation: %s", err)
|
|
|
|
}
|
|
|
|
|
2019-01-09 03:39:14 +01:00
|
|
|
config, hclDiags := loader.LoadConfig(rootDir)
|
|
|
|
diags = diags.Append(hclDiags)
|
|
|
|
return config, loader, cleanup, diags
|
|
|
|
}
|
|
|
|
|
|
|
|
// MustLoadConfigForTests is a variant of LoadConfigForTests which calls
|
|
|
|
// t.Fatal (or similar) if there are any errors during loading, and thus
|
|
|
|
// does not return diagnostics at all.
|
|
|
|
//
|
|
|
|
// This is useful for concisely writing tests that don't expect errors at
|
|
|
|
// all. For tests that expect errors and need to assert against them, use
|
|
|
|
// LoadConfigForTests instead.
|
|
|
|
func MustLoadConfigForTests(t *testing.T, rootDir string) (*configs.Config, *configload.Loader, func()) {
|
|
|
|
t.Helper()
|
|
|
|
|
|
|
|
config, loader, cleanup, diags := LoadConfigForTests(t, rootDir)
|
|
|
|
if diags.HasErrors() {
|
|
|
|
cleanup()
|
|
|
|
t.Fatal(diags.Err())
|
|
|
|
}
|
|
|
|
return config, loader, cleanup
|
|
|
|
}
|