ResiLien
/
terraform
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
terraform/backend/local/backend_plan_test.go

890 lines
24 KiB
Go
Raw Normal View History

backend/local The local backend implementation is an implementation of backend.Enhanced that recreates all the behavior of the CLI but through the backend interface.
2017-01-19 05:47:56 +01:00
package local
import (
"context"
"os"
"path/filepath"
backend/local: validate module exists for plan Fixes #11504 The local backend should error if `terraform plan` is called in a directory with no Terraform config files (same behavior as 0.8.x). **New behavior:** We now allow `terraform plan -destroy` with no configuration files since that seems reasonable.
2017-01-30 04:51:54 +01:00
"strings"
backend/local The local backend implementation is an implementation of backend.Enhanced that recreates all the behavior of the CLI but through the backend interface.
2017-01-19 05:47:56 +01:00
"testing"
backend/local tests tests tests converted the existing testPlanState() from terraform.State to states.State to fix various plan tests. reverted the "bandaid" in plans/planfile/tfplan.go - at this moment the backend tests do not include backend configuration, and so the planfile package can write the plan file but not read it back in. That will be revisted in a separate track of work.
2018-10-09 00:22:59 +02:00
"github.com/hashicorp/terraform/addrs"
backend/local The local backend implementation is an implementation of backend.Enhanced that recreates all the behavior of the CLI but through the backend interface.
2017-01-19 05:47:56 +01:00
"github.com/hashicorp/terraform/backend"
backend/local WIP commit - fixing tests
2018-09-28 23:04:57 +02:00
"github.com/hashicorp/terraform/configs/configschema"
Move module install functionality over to internal/initwd
2019-01-09 03:39:14 +01:00
"github.com/hashicorp/terraform/internal/initwd"
plans/objchange: further harden ProposedNewObject against ~weird~ incoming values Addresses an odd state where the priorV of an object to be changed is known but null. While this situation should not happen, it seemed prudent to ensure that core is resilient to providers sending incorrect values (which might also occur with manually edited state).
2018-09-29 00:57:27 +02:00
"github.com/hashicorp/terraform/plans"
"github.com/hashicorp/terraform/plans/planfile"
backend/local tests tests tests converted the existing testPlanState() from terraform.State to states.State to fix various plan tests. reverted the "bandaid" in plans/planfile/tfplan.go - at this moment the backend tests do not include backend configuration, and so the planfile package can write the plan file but not read it back in. That will be revisted in a separate track of work.
2018-10-09 00:22:59 +02:00
"github.com/hashicorp/terraform/states"
backend/local The local backend implementation is an implementation of backend.Enhanced that recreates all the behavior of the CLI but through the backend interface.
2017-01-19 05:47:56 +01:00
"github.com/hashicorp/terraform/terraform"
cli: allow disabling "next steps" message in terraform plan In #15884 we adjusted the plan output to give an explicit command to run to apply a plan, whereas before this command was just alluded to in the prose. Since releasing that, we've got good feedback that it's confusing to include such instructions when Terraform is running in a workflow automation tool, because such tools usually abstract away exactly what commands are run and require users to take different actions to proceed through the workflow. To accommodate such environments while retaining helpful messages for normal CLI usage, here we introduce a new environment variable TF_IN_AUTOMATION which, when set to a non-empty value, is a hint to Terraform that it isn't being run in an interactive command shell and it should thus tone down the "next steps" messaging. The documentation for this setting is included as part of the "...in automation" guide since it's not generally useful in other cases. We also intentionally disclaim comprehensive support for this since we want to avoid creating an extreme number of "if running in automation..." codepaths that would increase the testing matrix and hurt maintainability. The focus is specifically on the output of the three commands we give in the automation guide, which at present means the following two situations: * "terraform init" does not include the final paragraphs that suggest running "terraform plan" and tell you in what situations you might need to re-run "terraform init". * "terraform plan" does not include the final paragraphs that either warn about not specifying "-out=..." or instruct to run "terraform apply" with the generated plan file.
2017-09-09 02:14:37 +02:00
"github.com/mitchellh/cli"
backend/local: Update tests for changes in "terraform" package This mainly consists of adding schema information to the mock providers.
2018-05-23 04:57:04 +02:00
"github.com/zclconf/go-cty/cty"
backend/local The local backend implementation is an implementation of backend.Enhanced that recreates all the behavior of the CLI but through the backend interface.
2017-01-19 05:47:56 +01:00
)
func TestLocal_planBasic(t *testing.T) {
cleanup temp files from backend tests
2018-03-28 16:54:08 +02:00
b, cleanup := TestLocal(t)
defer cleanup()
backend/local: Update tests for changes in "terraform" package This mainly consists of adding schema information to the mock providers.
2018-05-23 04:57:04 +02:00
p := TestLocalProvider(t, b, "test", planFixtureSchema())
backend/local The local backend implementation is an implementation of backend.Enhanced that recreates all the behavior of the CLI but through the backend interface.
2017-01-19 05:47:56 +01:00
Standardise directory name for test data
2019-06-30 09:38:36 +02:00
op, configCleanup := testOperationPlan(t, "./testdata/plan")
backend: Update interface and implementations for new config loader The new config loader requires some steps to happen in a different order, particularly in regard to knowing the schema in order to decode the configuration. Here we lean directly on the configschema package, rather than on helper/schema.Backend as before, because it's generally sufficient for our needs here and this prepares us for the helper/schema package later moving out into its own repository to seed a "plugin SDK".
2018-03-21 02:43:02 +01:00
defer configCleanup()
backend/local The local backend implementation is an implementation of backend.Enhanced that recreates all the behavior of the CLI but through the backend interface.
2017-01-19 05:47:56 +01:00
op.PlanRefresh = true
run, err := b.Operation(context.Background(), op)
if err != nil {
t.Fatalf("bad: %s", err)
}
<-run.Done()
backend: Update interface and implementations for new config loader The new config loader requires some steps to happen in a different order, particularly in regard to knowing the schema in order to decode the configuration. Here we lean directly on the configschema package, rather than on helper/schema.Backend as before, because it's generally sufficient for our needs here and this prepares us for the helper/schema package later moving out into its own repository to seed a "plugin SDK".
2018-03-21 02:43:02 +01:00
if run.Result != backend.OperationSuccess {
t.Fatalf("plan operation failed")
backend/local The local backend implementation is an implementation of backend.Enhanced that recreates all the behavior of the CLI but through the backend interface.
2017-01-19 05:47:56 +01:00
}
backend/local WIP commit - fixing tests
2018-09-28 23:04:57 +02:00
if !p.PlanResourceChangeCalled {
t.Fatal("PlanResourceChange should be called")
backend/local The local backend implementation is an implementation of backend.Enhanced that recreates all the behavior of the CLI but through the backend interface.
2017-01-19 05:47:56 +01:00
}
* backend/local: push responsibility for unlocking state into individual operations * unlock the state if Context() has an error, exactly as backend/remote does today * terraform console and terraform import will exit before unlocking state in case of error in Context() * responsibility for unlocking state in the local backend is pushed down the stack, out of backend.go and into each individual state operation * add tests confirming that state is not locked after apply and plan * backend/local: add checks that the state is unlocked after operations This adds tests to plan, apply and refresh which validate that the state is unlocked after all operations, regardless of exit status. I've also added specific tests that force Context() to fail during each operation to verify that locking behavior specifically.
2020-08-11 17:23:42 +02:00
// the backend should be unlocked after a run
assertBackendStateUnlocked(t, b)
backend/local The local backend implementation is an implementation of backend.Enhanced that recreates all the behavior of the CLI but through the backend interface.
2017-01-19 05:47:56 +01:00
}
cli: allow disabling "next steps" message in terraform plan In #15884 we adjusted the plan output to give an explicit command to run to apply a plan, whereas before this command was just alluded to in the prose. Since releasing that, we've got good feedback that it's confusing to include such instructions when Terraform is running in a workflow automation tool, because such tools usually abstract away exactly what commands are run and require users to take different actions to proceed through the workflow. To accommodate such environments while retaining helpful messages for normal CLI usage, here we introduce a new environment variable TF_IN_AUTOMATION which, when set to a non-empty value, is a hint to Terraform that it isn't being run in an interactive command shell and it should thus tone down the "next steps" messaging. The documentation for this setting is included as part of the "...in automation" guide since it's not generally useful in other cases. We also intentionally disclaim comprehensive support for this since we want to avoid creating an extreme number of "if running in automation..." codepaths that would increase the testing matrix and hurt maintainability. The focus is specifically on the output of the three commands we give in the automation guide, which at present means the following two situations: * "terraform init" does not include the final paragraphs that suggest running "terraform plan" and tell you in what situations you might need to re-run "terraform init". * "terraform plan" does not include the final paragraphs that either warn about not specifying "-out=..." or instruct to run "terraform apply" with the generated plan file.
2017-09-09 02:14:37 +02:00
func TestLocal_planInAutomation(t *testing.T) {
cleanup temp files from backend tests
2018-03-28 16:54:08 +02:00
b, cleanup := TestLocal(t)
defer cleanup()
backend/local: Update tests for changes in "terraform" package This mainly consists of adding schema information to the mock providers.
2018-05-23 04:57:04 +02:00
TestLocalProvider(t, b, "test", planFixtureSchema())
cli: allow disabling "next steps" message in terraform plan In #15884 we adjusted the plan output to give an explicit command to run to apply a plan, whereas before this command was just alluded to in the prose. Since releasing that, we've got good feedback that it's confusing to include such instructions when Terraform is running in a workflow automation tool, because such tools usually abstract away exactly what commands are run and require users to take different actions to proceed through the workflow. To accommodate such environments while retaining helpful messages for normal CLI usage, here we introduce a new environment variable TF_IN_AUTOMATION which, when set to a non-empty value, is a hint to Terraform that it isn't being run in an interactive command shell and it should thus tone down the "next steps" messaging. The documentation for this setting is included as part of the "...in automation" guide since it's not generally useful in other cases. We also intentionally disclaim comprehensive support for this since we want to avoid creating an extreme number of "if running in automation..." codepaths that would increase the testing matrix and hurt maintainability. The focus is specifically on the output of the three commands we give in the automation guide, which at present means the following two situations: * "terraform init" does not include the final paragraphs that suggest running "terraform plan" and tell you in what situations you might need to re-run "terraform init". * "terraform plan" does not include the final paragraphs that either warn about not specifying "-out=..." or instruct to run "terraform apply" with the generated plan file.
2017-09-09 02:14:37 +02:00
backend/local: Use terminal properties to tweak the plan output We now require the output to accept UTF-8 and we can determine how wide the terminal (if any) is, so here we begin to make use of that for the "terraform plan" command. The horizontal rule is now made of box drawing characters instead of hyphens and fills the whole terminal width. The paragraphs of text in the output are now also wrapped to fill the terminal width, instead of the hard-wrapping we did before. This is just a start down the road of making better use of the terminal capabilities. Lots of other commands could benefit from updates like these too.
2021-01-12 03:29:39 +01:00
const msg = `You didn't use the -out option`
cli: allow disabling "next steps" message in terraform plan In #15884 we adjusted the plan output to give an explicit command to run to apply a plan, whereas before this command was just alluded to in the prose. Since releasing that, we've got good feedback that it's confusing to include such instructions when Terraform is running in a workflow automation tool, because such tools usually abstract away exactly what commands are run and require users to take different actions to proceed through the workflow. To accommodate such environments while retaining helpful messages for normal CLI usage, here we introduce a new environment variable TF_IN_AUTOMATION which, when set to a non-empty value, is a hint to Terraform that it isn't being run in an interactive command shell and it should thus tone down the "next steps" messaging. The documentation for this setting is included as part of the "...in automation" guide since it's not generally useful in other cases. We also intentionally disclaim comprehensive support for this since we want to avoid creating an extreme number of "if running in automation..." codepaths that would increase the testing matrix and hurt maintainability. The focus is specifically on the output of the three commands we give in the automation guide, which at present means the following two situations: * "terraform init" does not include the final paragraphs that suggest running "terraform plan" and tell you in what situations you might need to re-run "terraform init". * "terraform plan" does not include the final paragraphs that either warn about not specifying "-out=..." or instruct to run "terraform apply" with the generated plan file.
2017-09-09 02:14:37 +02:00
// When we're "in automation" we omit certain text from the
// plan output. However, testing for the absense of text is
// unreliable in the face of future copy changes, so we'll
// mitigate that by running both with and without the flag
// set so we can ensure that the expected messages _are_
// included the first time.
b.RunningInAutomation = false
b.CLI = cli.NewMockUi()
{
Standardise directory name for test data
2019-06-30 09:38:36 +02:00
op, configCleanup := testOperationPlan(t, "./testdata/plan")
backend: Update interface and implementations for new config loader The new config loader requires some steps to happen in a different order, particularly in regard to knowing the schema in order to decode the configuration. Here we lean directly on the configschema package, rather than on helper/schema.Backend as before, because it's generally sufficient for our needs here and this prepares us for the helper/schema package later moving out into its own repository to seed a "plugin SDK".
2018-03-21 02:43:02 +01:00
defer configCleanup()
cli: allow disabling "next steps" message in terraform plan In #15884 we adjusted the plan output to give an explicit command to run to apply a plan, whereas before this command was just alluded to in the prose. Since releasing that, we've got good feedback that it's confusing to include such instructions when Terraform is running in a workflow automation tool, because such tools usually abstract away exactly what commands are run and require users to take different actions to proceed through the workflow. To accommodate such environments while retaining helpful messages for normal CLI usage, here we introduce a new environment variable TF_IN_AUTOMATION which, when set to a non-empty value, is a hint to Terraform that it isn't being run in an interactive command shell and it should thus tone down the "next steps" messaging. The documentation for this setting is included as part of the "...in automation" guide since it's not generally useful in other cases. We also intentionally disclaim comprehensive support for this since we want to avoid creating an extreme number of "if running in automation..." codepaths that would increase the testing matrix and hurt maintainability. The focus is specifically on the output of the three commands we give in the automation guide, which at present means the following two situations: * "terraform init" does not include the final paragraphs that suggest running "terraform plan" and tell you in what situations you might need to re-run "terraform init". * "terraform plan" does not include the final paragraphs that either warn about not specifying "-out=..." or instruct to run "terraform apply" with the generated plan file.
2017-09-09 02:14:37 +02:00
op.PlanRefresh = true
run, err := b.Operation(context.Background(), op)
if err != nil {
t.Fatalf("unexpected error: %s", err)
}
<-run.Done()
backend: Update interface and implementations for new config loader The new config loader requires some steps to happen in a different order, particularly in regard to knowing the schema in order to decode the configuration. Here we lean directly on the configschema package, rather than on helper/schema.Backend as before, because it's generally sufficient for our needs here and this prepares us for the helper/schema package later moving out into its own repository to seed a "plugin SDK".
2018-03-21 02:43:02 +01:00
if run.Result != backend.OperationSuccess {
t.Fatalf("plan operation failed")
cli: allow disabling "next steps" message in terraform plan In #15884 we adjusted the plan output to give an explicit command to run to apply a plan, whereas before this command was just alluded to in the prose. Since releasing that, we've got good feedback that it's confusing to include such instructions when Terraform is running in a workflow automation tool, because such tools usually abstract away exactly what commands are run and require users to take different actions to proceed through the workflow. To accommodate such environments while retaining helpful messages for normal CLI usage, here we introduce a new environment variable TF_IN_AUTOMATION which, when set to a non-empty value, is a hint to Terraform that it isn't being run in an interactive command shell and it should thus tone down the "next steps" messaging. The documentation for this setting is included as part of the "...in automation" guide since it's not generally useful in other cases. We also intentionally disclaim comprehensive support for this since we want to avoid creating an extreme number of "if running in automation..." codepaths that would increase the testing matrix and hurt maintainability. The focus is specifically on the output of the three commands we give in the automation guide, which at present means the following two situations: * "terraform init" does not include the final paragraphs that suggest running "terraform plan" and tell you in what situations you might need to re-run "terraform init". * "terraform plan" does not include the final paragraphs that either warn about not specifying "-out=..." or instruct to run "terraform apply" with the generated plan file.
2017-09-09 02:14:37 +02:00
}
output := b.CLI.(*cli.MockUi).OutputWriter.String()
if !strings.Contains(output, msg) {
backend/local: Use terminal properties to tweak the plan output We now require the output to accept UTF-8 and we can determine how wide the terminal (if any) is, so here we begin to make use of that for the "terraform plan" command. The horizontal rule is now made of box drawing characters instead of hyphens and fills the whole terminal width. The paragraphs of text in the output are now also wrapped to fill the terminal width, instead of the hard-wrapping we did before. This is just a start down the road of making better use of the terminal capabilities. Lots of other commands could benefit from updates like these too.
2021-01-12 03:29:39 +01:00
t.Fatalf("missing next-steps message when not in automation\nwant: %s\noutput:\n%s", msg, output)
cli: allow disabling "next steps" message in terraform plan In #15884 we adjusted the plan output to give an explicit command to run to apply a plan, whereas before this command was just alluded to in the prose. Since releasing that, we've got good feedback that it's confusing to include such instructions when Terraform is running in a workflow automation tool, because such tools usually abstract away exactly what commands are run and require users to take different actions to proceed through the workflow. To accommodate such environments while retaining helpful messages for normal CLI usage, here we introduce a new environment variable TF_IN_AUTOMATION which, when set to a non-empty value, is a hint to Terraform that it isn't being run in an interactive command shell and it should thus tone down the "next steps" messaging. The documentation for this setting is included as part of the "...in automation" guide since it's not generally useful in other cases. We also intentionally disclaim comprehensive support for this since we want to avoid creating an extreme number of "if running in automation..." codepaths that would increase the testing matrix and hurt maintainability. The focus is specifically on the output of the three commands we give in the automation guide, which at present means the following two situations: * "terraform init" does not include the final paragraphs that suggest running "terraform plan" and tell you in what situations you might need to re-run "terraform init". * "terraform plan" does not include the final paragraphs that either warn about not specifying "-out=..." or instruct to run "terraform apply" with the generated plan file.
2017-09-09 02:14:37 +02:00
}
}
// On the second run, we expect the next-steps messaging to be absent
// since we're now "running in automation".
b.RunningInAutomation = true
b.CLI = cli.NewMockUi()
{
Standardise directory name for test data
2019-06-30 09:38:36 +02:00
op, configCleanup := testOperationPlan(t, "./testdata/plan")
backend: Update interface and implementations for new config loader The new config loader requires some steps to happen in a different order, particularly in regard to knowing the schema in order to decode the configuration. Here we lean directly on the configschema package, rather than on helper/schema.Backend as before, because it's generally sufficient for our needs here and this prepares us for the helper/schema package later moving out into its own repository to seed a "plugin SDK".
2018-03-21 02:43:02 +01:00
defer configCleanup()
cli: allow disabling "next steps" message in terraform plan In #15884 we adjusted the plan output to give an explicit command to run to apply a plan, whereas before this command was just alluded to in the prose. Since releasing that, we've got good feedback that it's confusing to include such instructions when Terraform is running in a workflow automation tool, because such tools usually abstract away exactly what commands are run and require users to take different actions to proceed through the workflow. To accommodate such environments while retaining helpful messages for normal CLI usage, here we introduce a new environment variable TF_IN_AUTOMATION which, when set to a non-empty value, is a hint to Terraform that it isn't being run in an interactive command shell and it should thus tone down the "next steps" messaging. The documentation for this setting is included as part of the "...in automation" guide since it's not generally useful in other cases. We also intentionally disclaim comprehensive support for this since we want to avoid creating an extreme number of "if running in automation..." codepaths that would increase the testing matrix and hurt maintainability. The focus is specifically on the output of the three commands we give in the automation guide, which at present means the following two situations: * "terraform init" does not include the final paragraphs that suggest running "terraform plan" and tell you in what situations you might need to re-run "terraform init". * "terraform plan" does not include the final paragraphs that either warn about not specifying "-out=..." or instruct to run "terraform apply" with the generated plan file.
2017-09-09 02:14:37 +02:00
op.PlanRefresh = true
run, err := b.Operation(context.Background(), op)
if err != nil {
t.Fatalf("unexpected error: %s", err)
}
<-run.Done()
backend: Update interface and implementations for new config loader The new config loader requires some steps to happen in a different order, particularly in regard to knowing the schema in order to decode the configuration. Here we lean directly on the configschema package, rather than on helper/schema.Backend as before, because it's generally sufficient for our needs here and this prepares us for the helper/schema package later moving out into its own repository to seed a "plugin SDK".
2018-03-21 02:43:02 +01:00
if run.Result != backend.OperationSuccess {
t.Fatalf("plan operation failed")
cli: allow disabling "next steps" message in terraform plan In #15884 we adjusted the plan output to give an explicit command to run to apply a plan, whereas before this command was just alluded to in the prose. Since releasing that, we've got good feedback that it's confusing to include such instructions when Terraform is running in a workflow automation tool, because such tools usually abstract away exactly what commands are run and require users to take different actions to proceed through the workflow. To accommodate such environments while retaining helpful messages for normal CLI usage, here we introduce a new environment variable TF_IN_AUTOMATION which, when set to a non-empty value, is a hint to Terraform that it isn't being run in an interactive command shell and it should thus tone down the "next steps" messaging. The documentation for this setting is included as part of the "...in automation" guide since it's not generally useful in other cases. We also intentionally disclaim comprehensive support for this since we want to avoid creating an extreme number of "if running in automation..." codepaths that would increase the testing matrix and hurt maintainability. The focus is specifically on the output of the three commands we give in the automation guide, which at present means the following two situations: * "terraform init" does not include the final paragraphs that suggest running "terraform plan" and tell you in what situations you might need to re-run "terraform init". * "terraform plan" does not include the final paragraphs that either warn about not specifying "-out=..." or instruct to run "terraform apply" with the generated plan file.
2017-09-09 02:14:37 +02:00
}
output := b.CLI.(*cli.MockUi).OutputWriter.String()
if strings.Contains(output, msg) {
t.Fatalf("next-steps message present when in automation")
}
}
}
backend/local: validate module exists for plan Fixes #11504 The local backend should error if `terraform plan` is called in a directory with no Terraform config files (same behavior as 0.8.x). **New behavior:** We now allow `terraform plan -destroy` with no configuration files since that seems reasonable.
2017-01-30 04:51:54 +01:00
func TestLocal_planNoConfig(t *testing.T) {
cleanup temp files from backend tests
2018-03-28 16:54:08 +02:00
b, cleanup := TestLocal(t)
defer cleanup()
backend/local: Update tests for changes in "terraform" package This mainly consists of adding schema information to the mock providers.
2018-05-23 04:57:04 +02:00
TestLocalProvider(t, b, "test", &terraform.ProviderSchema{})
backend/local: validate module exists for plan Fixes #11504 The local backend should error if `terraform plan` is called in a directory with no Terraform config files (same behavior as 0.8.x). **New behavior:** We now allow `terraform plan -destroy` with no configuration files since that seems reasonable.
2017-01-30 04:51:54 +01:00
backend: Update interface and implementations for new config loader The new config loader requires some steps to happen in a different order, particularly in regard to knowing the schema in order to decode the configuration. Here we lean directly on the configschema package, rather than on helper/schema.Backend as before, because it's generally sufficient for our needs here and this prepares us for the helper/schema package later moving out into its own repository to seed a "plugin SDK".
2018-03-21 02:43:02 +01:00
b.CLI = cli.NewMockUi()
Standardise directory name for test data
2019-06-30 09:38:36 +02:00
op, configCleanup := testOperationPlan(t, "./testdata/empty")
backend: Update interface and implementations for new config loader The new config loader requires some steps to happen in a different order, particularly in regard to knowing the schema in order to decode the configuration. Here we lean directly on the configschema package, rather than on helper/schema.Backend as before, because it's generally sufficient for our needs here and this prepares us for the helper/schema package later moving out into its own repository to seed a "plugin SDK".
2018-03-21 02:43:02 +01:00
defer configCleanup()
backend/local: validate module exists for plan Fixes #11504 The local backend should error if `terraform plan` is called in a directory with no Terraform config files (same behavior as 0.8.x). **New behavior:** We now allow `terraform plan -destroy` with no configuration files since that seems reasonable.
2017-01-30 04:51:54 +01:00
op.PlanRefresh = true
run, err := b.Operation(context.Background(), op)
if err != nil {
t.Fatalf("bad: %s", err)
}
<-run.Done()
backend: Update interface and implementations for new config loader The new config loader requires some steps to happen in a different order, particularly in regard to knowing the schema in order to decode the configuration. Here we lean directly on the configschema package, rather than on helper/schema.Backend as before, because it's generally sufficient for our needs here and this prepares us for the helper/schema package later moving out into its own repository to seed a "plugin SDK".
2018-03-21 02:43:02 +01:00
if run.Result == backend.OperationSuccess {
t.Fatal("plan operation succeeded; want failure")
backend/local: validate module exists for plan Fixes #11504 The local backend should error if `terraform plan` is called in a directory with no Terraform config files (same behavior as 0.8.x). **New behavior:** We now allow `terraform plan -destroy` with no configuration files since that seems reasonable.
2017-01-30 04:51:54 +01:00
}
backend: Update interface and implementations for new config loader The new config loader requires some steps to happen in a different order, particularly in regard to knowing the schema in order to decode the configuration. Here we lean directly on the configschema package, rather than on helper/schema.Backend as before, because it's generally sufficient for our needs here and this prepares us for the helper/schema package later moving out into its own repository to seed a "plugin SDK".
2018-03-21 02:43:02 +01:00
output := b.CLI.(*cli.MockUi).ErrorWriter.String()
if !strings.Contains(output, "configuration") {
backend/local: validate module exists for plan Fixes #11504 The local backend should error if `terraform plan` is called in a directory with no Terraform config files (same behavior as 0.8.x). **New behavior:** We now allow `terraform plan -destroy` with no configuration files since that seems reasonable.
2017-01-30 04:51:54 +01:00
t.Fatalf("bad: %s", err)
}
* backend/local: push responsibility for unlocking state into individual operations * unlock the state if Context() has an error, exactly as backend/remote does today * terraform console and terraform import will exit before unlocking state in case of error in Context() * responsibility for unlocking state in the local backend is pushed down the stack, out of backend.go and into each individual state operation * add tests confirming that state is not locked after apply and plan * backend/local: add checks that the state is unlocked after operations This adds tests to plan, apply and refresh which validate that the state is unlocked after all operations, regardless of exit status. I've also added specific tests that force Context() to fail during each operation to verify that locking behavior specifically.
2020-08-11 17:23:42 +02:00
// the backend should be unlocked after a run
assertBackendStateUnlocked(t, b)
}
// This test validates the state lacking behavior when the inner call to
// Context() fails
func TestLocal_plan_context_error(t *testing.T) {
b, cleanup := TestLocal(t)
defer cleanup()
op, configCleanup := testOperationPlan(t, "./testdata/plan")
defer configCleanup()
op.PlanRefresh = true
// we coerce a failure in Context() by omitting the provider schema
run, err := b.Operation(context.Background(), op)
if err != nil {
t.Fatalf("bad: %s", err)
}
<-run.Done()
if run.Result != backend.OperationFailure {
t.Fatalf("plan operation succeeded")
}
// the backend should be unlocked after a run
assertBackendStateUnlocked(t, b)
backend/local: validate module exists for plan Fixes #11504 The local backend should error if `terraform plan` is called in a directory with no Terraform config files (same behavior as 0.8.x). **New behavior:** We now allow `terraform plan -destroy` with no configuration files since that seems reasonable.
2017-01-30 04:51:54 +01:00
}
backend/local: treat output changes as side-effects to be applied This is a baby-step towards an intended future where all Terraform actions which have side-effects in either remote objects or the Terraform state can go through the plan+apply workflow. This initial change is focused only on allowing plan+apply for changes to root module output values, so that these can be written into a new state snapshot (for consumption by terraform_remote_state elsewhere) without having to go outside of the primary workflow by running "terraform refresh". This is also better than "terraform refresh" because it gives an opportunity to review the proposed changes before applying them, as we're accustomed to with resource changes. The downside here is that Terraform Core was not designed to produce accurate changesets for root module outputs. Although we added a place for it in the plan model in Terraform 0.12, Terraform Core currently produces inaccurate changesets there which don't properly track the prior values. We're planning to rework Terraform Core's evaluation approach in a forthcoming release so it would itself be able to distinguish between the prior state and the planned new state to produce an accurate changeset, but this commit introduces a temporary stop-gap solution of implementing the logic up in the local backend code, where we can freeze a snapshot of the prior state before we take any other actions and then use that to produce an accurate output changeset to decide whether the plan has externally-visible side-effects and render any changes to output values. This temporary approach should be replaced by a more appropriately-placed solution in Terraform Core in a release, which should then allow further behaviors in similar vein, such as user-visible drift detection for resource instances.
2020-05-27 01:59:06 +02:00
func TestLocal_planOutputsChanged(t *testing.T) {
b, cleanup := TestLocal(t)
defer cleanup()
testStateFile(t, b.StatePath, states.BuildState(func(ss *states.SyncState) {
ss.SetOutputValue(addrs.AbsOutputValue{
Module: addrs.RootModuleInstance,
OutputValue: addrs.OutputValue{Name: "changed"},
}, cty.StringVal("before"), false)
ss.SetOutputValue(addrs.AbsOutputValue{
Module: addrs.RootModuleInstance,
OutputValue: addrs.OutputValue{Name: "sensitive_before"},
}, cty.StringVal("before"), true)
ss.SetOutputValue(addrs.AbsOutputValue{
Module: addrs.RootModuleInstance,
OutputValue: addrs.OutputValue{Name: "sensitive_after"},
}, cty.StringVal("before"), false)
ss.SetOutputValue(addrs.AbsOutputValue{
Module: addrs.RootModuleInstance,
OutputValue: addrs.OutputValue{Name: "removed"}, // not present in the config fixture
}, cty.StringVal("before"), false)
ss.SetOutputValue(addrs.AbsOutputValue{
Module: addrs.RootModuleInstance,
OutputValue: addrs.OutputValue{Name: "unchanged"},
}, cty.StringVal("before"), false)
// NOTE: This isn't currently testing the situation where the new
// value of an output is unknown, because to do that requires there to
// be at least one managed resource Create action in the plan and that
// would defeat the point of this test, which is to ensure that a
// plan containing only output changes is considered "non-empty".
// For now we're not too worried about testing the "new value is
// unknown" situation because that's already common for printing out
// resource changes and we already have many tests for that.
}))
b.CLI = cli.NewMockUi()
outDir := testTempDir(t)
defer os.RemoveAll(outDir)
planPath := filepath.Join(outDir, "plan.tfplan")
op, configCleanup := testOperationPlan(t, "./testdata/plan-outputs-changed")
defer configCleanup()
op.PlanRefresh = true
op.PlanOutPath = planPath
cfg := cty.ObjectVal(map[string]cty.Value{
"path": cty.StringVal(b.StatePath),
})
cfgRaw, err := plans.NewDynamicValue(cfg, cfg.Type())
if err != nil {
t.Fatal(err)
}
op.PlanOutBackend = &plans.Backend{
// Just a placeholder so that we can generate a valid plan file.
Type: "local",
Config: cfgRaw,
}
run, err := b.Operation(context.Background(), op)
if err != nil {
t.Fatalf("bad: %s", err)
}
<-run.Done()
if run.Result != backend.OperationSuccess {
t.Fatalf("plan operation failed")
}
if run.PlanEmpty {
t.Fatal("plan should not be empty")
}
expectedOutput := strings.TrimSpace(`
Plan: 0 to add, 0 to change, 0 to destroy.
Changes to Outputs:
+ added = "after"
~ changed = "before" -> "after"
- removed = "before" -> null
~ sensitive_after = (sensitive value)
~ sensitive_before = (sensitive value)
`)
output := b.CLI.(*cli.MockUi).OutputWriter.String()
if !strings.Contains(output, expectedOutput) {
t.Fatalf("Unexpected output:\n%s\n\nwant output containing:\n%s", output, expectedOutput)
}
}
output test for plan with no root output changes Module outputs do not show up in the plan, and are not rendered in the UI.
2020-11-17 22:11:57 +01:00
// Module outputs should not cause the plan to be rendered
func TestLocal_planModuleOutputsChanged(t *testing.T) {
b, cleanup := TestLocal(t)
defer cleanup()
testStateFile(t, b.StatePath, states.BuildState(func(ss *states.SyncState) {
ss.SetOutputValue(addrs.AbsOutputValue{
Module: addrs.RootModuleInstance.Child("mod", addrs.NoKey),
OutputValue: addrs.OutputValue{Name: "changed"},
}, cty.StringVal("before"), false)
}))
b.CLI = cli.NewMockUi()
outDir := testTempDir(t)
defer os.RemoveAll(outDir)
planPath := filepath.Join(outDir, "plan.tfplan")
op, configCleanup := testOperationPlan(t, "./testdata/plan-module-outputs-changed")
defer configCleanup()
op.PlanRefresh = true
op.PlanOutPath = planPath
cfg := cty.ObjectVal(map[string]cty.Value{
"path": cty.StringVal(b.StatePath),
})
cfgRaw, err := plans.NewDynamicValue(cfg, cfg.Type())
if err != nil {
t.Fatal(err)
}
op.PlanOutBackend = &plans.Backend{
Type: "local",
Config: cfgRaw,
}
run, err := b.Operation(context.Background(), op)
if err != nil {
t.Fatalf("bad: %s", err)
}
<-run.Done()
if run.Result != backend.OperationSuccess {
t.Fatalf("plan operation failed")
}
if !run.PlanEmpty {
t.Fatal("plan should be empty")
}
expectedOutput := strings.TrimSpace(`
No changes. Infrastructure is up-to-date.
`)
output := b.CLI.(*cli.MockUi).OutputWriter.String()
if !strings.Contains(output, expectedOutput) {
t.Fatalf("Unexpected output:\n%s\n\nwant output containing:\n%s", output, expectedOutput)
}
}
backend/local: Render CBD replacement (+/-) correctly (#19642) * backend/local: Render CBD replacement (+/-) correctly * command/format: Use IsReplace helper function
2018-12-14 14:45:47 +01:00
func TestLocal_planTainted(t *testing.T) {
b, cleanup := TestLocal(t)
defer cleanup()
p := TestLocalProvider(t, b, "test", planFixtureSchema())
testStateFile(t, b.StatePath, testPlanState_tainted())
b.CLI = cli.NewMockUi()
outDir := testTempDir(t)
defer os.RemoveAll(outDir)
planPath := filepath.Join(outDir, "plan.tfplan")
Standardise directory name for test data
2019-06-30 09:38:36 +02:00
op, configCleanup := testOperationPlan(t, "./testdata/plan")
backend/local: Render CBD replacement (+/-) correctly (#19642) * backend/local: Render CBD replacement (+/-) correctly * command/format: Use IsReplace helper function
2018-12-14 14:45:47 +01:00
defer configCleanup()
op.PlanRefresh = true
op.PlanOutPath = planPath
cfg := cty.ObjectVal(map[string]cty.Value{
"path": cty.StringVal(b.StatePath),
})
cfgRaw, err := plans.NewDynamicValue(cfg, cfg.Type())
if err != nil {
t.Fatal(err)
}
op.PlanOutBackend = &plans.Backend{
// Just a placeholder so that we can generate a valid plan file.
Type: "local",
Config: cfgRaw,
}
run, err := b.Operation(context.Background(), op)
if err != nil {
t.Fatalf("bad: %s", err)
}
<-run.Done()
if run.Result != backend.OperationSuccess {
t.Fatalf("plan operation failed")
}
if !p.ReadResourceCalled {
t.Fatal("ReadResource should be called")
}
if run.PlanEmpty {
t.Fatal("plan should not be empty")
}
backend/local: Use terminal properties to tweak the plan output We now require the output to accept UTF-8 and we can determine how wide the terminal (if any) is, so here we begin to make use of that for the "terraform plan" command. The horizontal rule is now made of box drawing characters instead of hyphens and fills the whole terminal width. The paragraphs of text in the output are now also wrapped to fill the terminal width, instead of the hard-wrapping we did before. This is just a start down the road of making better use of the terminal capabilities. Lots of other commands could benefit from updates like these too.
2021-01-12 03:29:39 +01:00
expectedOutput := `Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
backend/local: Render CBD replacement (+/-) correctly (#19642) * backend/local: Render CBD replacement (+/-) correctly * command/format: Use IsReplace helper function
2018-12-14 14:45:47 +01:00
-/+ destroy and then create replacement
Terraform will perform the following actions:
command/plan: plan output should indicate if a resource is being (#20580) replaced because the instance was tainted.
2019-03-06 01:18:55 +01:00
# test_instance.foo is tainted, so must be replaced
backend/local: Render CBD replacement (+/-) correctly (#19642) * backend/local: Render CBD replacement (+/-) correctly * command/format: Use IsReplace helper function
2018-12-14 14:45:47 +01:00
-/+ resource "test_instance" "foo" {
command: Add experimental concise diff renderer When rendering a diff between current state and projected state, we only show resources and outputs which have changes. However, we show a full structural diff for these values, which includes all attributes and blocks for a changed resource or output. The result can be a very long diff, which makes it difficult to verify what the changed fields are. This commit adds an experimental concise diff renderer, which suppresses most unchanged fields, only displaying the most relevant changes and some identifying context. This means: - Always show all identifying attributes, initially defined as `id`, `name`, and `tags`, even if unchanged; - Only show changed, added, or removed primitive values: `string`, `number`, or `bool`; - Only show added or removed elements in unordered collections and structural types: `map`, `set`, and `object`; - Show added or removed elements with any surrounding unchanged elements for sequence types: `list` and `tuple`; - Only show added or removed nested blocks, or blocks with changed attributes. If any attributes, collection elements, or blocks are hidden, a count is kept and displayed at the end of the parent scope. This ensures that it is clear that the diff is only displaying a subset of the resource. The experiment is currently enabled by default, but can be disabled by setting the TF_X_CONCISE_DIFF environment variable to 0.
2020-08-19 22:47:56 +02:00
# (1 unchanged attribute hidden)
backend/local: Render CBD replacement (+/-) correctly (#19642) * backend/local: Render CBD replacement (+/-) correctly * command/format: Use IsReplace helper function
2018-12-14 14:45:47 +01:00
command: Add experimental concise diff renderer When rendering a diff between current state and projected state, we only show resources and outputs which have changes. However, we show a full structural diff for these values, which includes all attributes and blocks for a changed resource or output. The result can be a very long diff, which makes it difficult to verify what the changed fields are. This commit adds an experimental concise diff renderer, which suppresses most unchanged fields, only displaying the most relevant changes and some identifying context. This means: - Always show all identifying attributes, initially defined as `id`, `name`, and `tags`, even if unchanged; - Only show changed, added, or removed primitive values: `string`, `number`, or `bool`; - Only show added or removed elements in unordered collections and structural types: `map`, `set`, and `object`; - Show added or removed elements with any surrounding unchanged elements for sequence types: `list` and `tuple`; - Only show added or removed nested blocks, or blocks with changed attributes. If any attributes, collection elements, or blocks are hidden, a count is kept and displayed at the end of the parent scope. This ensures that it is clear that the diff is only displaying a subset of the resource. The experiment is currently enabled by default, but can be disabled by setting the TF_X_CONCISE_DIFF environment variable to 0.
2020-08-19 22:47:56 +02:00
# (1 unchanged block hidden)
backend/local: Render CBD replacement (+/-) correctly (#19642) * backend/local: Render CBD replacement (+/-) correctly * command/format: Use IsReplace helper function
2018-12-14 14:45:47 +01:00
}
Plan: 1 to add, 0 to change, 1 to destroy.`
output := b.CLI.(*cli.MockUi).OutputWriter.String()
if !strings.Contains(output, expectedOutput) {
t.Fatalf("Unexpected output:\n%s", output)
}
}
backend/local: don't panic when an instance has only a deposed object This unusual situation isn't supposed to arise in normal use, but it can come up in practice in some edge-case scenarios where Terraform fails in a severe way during a create_before_destroy. Some earlier versions of Terraform also had bugs in their handling of deposed objects, so this may also arise if upgrading from one of those older versions with some leftover deposed objects in the state.
2019-06-03 23:50:32 +02:00
func TestLocal_planDeposedOnly(t *testing.T) {
b, cleanup := TestLocal(t)
defer cleanup()
p := TestLocalProvider(t, b, "test", planFixtureSchema())
testStateFile(t, b.StatePath, states.BuildState(func(ss *states.SyncState) {
ss.SetResourceInstanceDeposed(
addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test_instance",
Name: "foo",
}.Instance(addrs.NoKey).Absolute(addrs.RootModuleInstance),
states.DeposedKey("00000000"),
&states.ResourceInstanceObjectSrc{
Status: states.ObjectReady,
AttrsJSON: []byte(`{
"ami": "bar",
"network_interface": [{
"device_index": 0,
"description": "Main network interface"
}]
}`),
},
addrs: embed Provider in AbsProviderConfig instead of Type a large refactor to addrs.AbsProviderConfig, embedding the addrs.Provider instead of a Type string. I've added and updated tests, added some Legacy functions to support older state formats and shims, and added a normalization step when reading v4 (current) state files (not the added tests under states/statefile/roundtrip which work with both current and legacy-style AbsProviderConfig strings). The remaining 'fixme' and 'todo' comments are mostly going to be addressed in a subsequent PR and involve looking up a given local provider config's FQN. This is fine for now as we are only working with default assumption.
2020-02-13 21:32:58 +01:00
addrs.AbsProviderConfig{
backend/local: refactor tests with modern state and default providers (#24524)
2020-04-01 21:07:05 +02:00
Provider: addrs.NewDefaultProvider("test"),
finish provider ModuleInstance replacement
2020-03-11 19:19:52 +01:00
Module: addrs.RootModule,
addrs: embed Provider in AbsProviderConfig instead of Type a large refactor to addrs.AbsProviderConfig, embedding the addrs.Provider instead of a Type string. I've added and updated tests, added some Legacy functions to support older state formats and shims, and added a normalization step when reading v4 (current) state files (not the added tests under states/statefile/roundtrip which work with both current and legacy-style AbsProviderConfig strings). The remaining 'fixme' and 'todo' comments are mostly going to be addressed in a subsequent PR and involve looking up a given local provider config's FQN. This is fine for now as we are only working with default assumption.
2020-02-13 21:32:58 +01:00
},
backend/local: don't panic when an instance has only a deposed object This unusual situation isn't supposed to arise in normal use, but it can come up in practice in some edge-case scenarios where Terraform fails in a severe way during a create_before_destroy. Some earlier versions of Terraform also had bugs in their handling of deposed objects, so this may also arise if upgrading from one of those older versions with some leftover deposed objects in the state.
2019-06-03 23:50:32 +02:00
)
}))
b.CLI = cli.NewMockUi()
outDir := testTempDir(t)
defer os.RemoveAll(outDir)
planPath := filepath.Join(outDir, "plan.tfplan")
Standardise directory name for test data
2019-06-30 09:38:36 +02:00
op, configCleanup := testOperationPlan(t, "./testdata/plan")
backend/local: don't panic when an instance has only a deposed object This unusual situation isn't supposed to arise in normal use, but it can come up in practice in some edge-case scenarios where Terraform fails in a severe way during a create_before_destroy. Some earlier versions of Terraform also had bugs in their handling of deposed objects, so this may also arise if upgrading from one of those older versions with some leftover deposed objects in the state.
2019-06-03 23:50:32 +02:00
defer configCleanup()
op.PlanRefresh = true
op.PlanOutPath = planPath
cfg := cty.ObjectVal(map[string]cty.Value{
"path": cty.StringVal(b.StatePath),
})
cfgRaw, err := plans.NewDynamicValue(cfg, cfg.Type())
if err != nil {
t.Fatal(err)
}
op.PlanOutBackend = &plans.Backend{
// Just a placeholder so that we can generate a valid plan file.
Type: "local",
Config: cfgRaw,
}
run, err := b.Operation(context.Background(), op)
if err != nil {
t.Fatalf("bad: %s", err)
}
<-run.Done()
if run.Result != backend.OperationSuccess {
t.Fatalf("plan operation failed")
}
fix local backend tests to match new behavior Leaving plan with -refresh=false tests failing for now.
2020-09-11 23:56:12 +02:00
if p.ReadResourceCalled {
t.Fatal("ReadResource should not be called")
backend/local: don't panic when an instance has only a deposed object This unusual situation isn't supposed to arise in normal use, but it can come up in practice in some edge-case scenarios where Terraform fails in a severe way during a create_before_destroy. Some earlier versions of Terraform also had bugs in their handling of deposed objects, so this may also arise if upgrading from one of those older versions with some leftover deposed objects in the state.
2019-06-03 23:50:32 +02:00
}
if run.PlanEmpty {
t.Fatal("plan should not be empty")
}
// The deposed object and the current object are distinct, so our
// plan includes separate actions for each of them. This strange situation
// is not common: it should arise only if Terraform fails during
// a create-before-destroy when the create hasn't completed yet but
// in a severe way that prevents the previous object from being restored
// as "current".
//
// However, that situation was more common in some earlier Terraform
// versions where deposed objects were not managed properly, so this
// can arise when upgrading from an older version with deposed objects
// already in the state.
//
// This is one of the few cases where we expose the idea of "deposed" in
// the UI, including the user-unfriendly "deposed key" (00000000 in this
// case) just so that users can correlate this with what they might
// see in `terraform show` and in the subsequent apply output, because
// it's also possible for there to be _multiple_ deposed objects, in the
// unlikely event that create_before_destroy _keeps_ crashing across
// subsequent runs.
backend/local: Use terminal properties to tweak the plan output We now require the output to accept UTF-8 and we can determine how wide the terminal (if any) is, so here we begin to make use of that for the "terraform plan" command. The horizontal rule is now made of box drawing characters instead of hyphens and fills the whole terminal width. The paragraphs of text in the output are now also wrapped to fill the terminal width, instead of the hard-wrapping we did before. This is just a start down the road of making better use of the terminal capabilities. Lots of other commands could benefit from updates like these too.
2021-01-12 03:29:39 +01:00
expectedOutput := `Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
backend/local: don't panic when an instance has only a deposed object This unusual situation isn't supposed to arise in normal use, but it can come up in practice in some edge-case scenarios where Terraform fails in a severe way during a create_before_destroy. Some earlier versions of Terraform also had bugs in their handling of deposed objects, so this may also arise if upgrading from one of those older versions with some leftover deposed objects in the state.
2019-06-03 23:50:32 +02:00
+ create
- destroy
Terraform will perform the following actions:
# test_instance.foo will be created
+ resource "test_instance" "foo" {
+ ami = "bar"
+ network_interface {
+ description = "Main network interface"
+ device_index = 0
}
}
# test_instance.foo (deposed object 00000000) will be destroyed
- resource "test_instance" "foo" {
- ami = "bar" -> null
- network_interface {
- description = "Main network interface" -> null
- device_index = 0 -> null
}
}
Plan: 1 to add, 0 to change, 1 to destroy.`
output := b.CLI.(*cli.MockUi).OutputWriter.String()
if !strings.Contains(output, expectedOutput) {
t.Fatalf("Unexpected output:\n%s\n\nwant output containing:\n%s", output, expectedOutput)
}
}
backend/local: Render CBD replacement (+/-) correctly (#19642) * backend/local: Render CBD replacement (+/-) correctly * command/format: Use IsReplace helper function
2018-12-14 14:45:47 +01:00
func TestLocal_planTainted_createBeforeDestroy(t *testing.T) {
b, cleanup := TestLocal(t)
defer cleanup()
p := TestLocalProvider(t, b, "test", planFixtureSchema())
testStateFile(t, b.StatePath, testPlanState_tainted())
b.CLI = cli.NewMockUi()
outDir := testTempDir(t)
defer os.RemoveAll(outDir)
planPath := filepath.Join(outDir, "plan.tfplan")
Standardise directory name for test data
2019-06-30 09:38:36 +02:00
op, configCleanup := testOperationPlan(t, "./testdata/plan-cbd")
backend/local: Render CBD replacement (+/-) correctly (#19642) * backend/local: Render CBD replacement (+/-) correctly * command/format: Use IsReplace helper function
2018-12-14 14:45:47 +01:00
defer configCleanup()
op.PlanRefresh = true
op.PlanOutPath = planPath
cfg := cty.ObjectVal(map[string]cty.Value{
"path": cty.StringVal(b.StatePath),
})
cfgRaw, err := plans.NewDynamicValue(cfg, cfg.Type())
if err != nil {
t.Fatal(err)
}
op.PlanOutBackend = &plans.Backend{
// Just a placeholder so that we can generate a valid plan file.
Type: "local",
Config: cfgRaw,
}
run, err := b.Operation(context.Background(), op)
if err != nil {
t.Fatalf("bad: %s", err)
}
<-run.Done()
if run.Result != backend.OperationSuccess {
t.Fatalf("plan operation failed")
}
if !p.ReadResourceCalled {
t.Fatal("ReadResource should be called")
}
if run.PlanEmpty {
t.Fatal("plan should not be empty")
}
backend/local: Use terminal properties to tweak the plan output We now require the output to accept UTF-8 and we can determine how wide the terminal (if any) is, so here we begin to make use of that for the "terraform plan" command. The horizontal rule is now made of box drawing characters instead of hyphens and fills the whole terminal width. The paragraphs of text in the output are now also wrapped to fill the terminal width, instead of the hard-wrapping we did before. This is just a start down the road of making better use of the terminal capabilities. Lots of other commands could benefit from updates like these too.
2021-01-12 03:29:39 +01:00
expectedOutput := `Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
backend/local: Render CBD replacement (+/-) correctly (#19642) * backend/local: Render CBD replacement (+/-) correctly * command/format: Use IsReplace helper function
2018-12-14 14:45:47 +01:00
+/- create replacement and then destroy
Terraform will perform the following actions:
command/plan: plan output should indicate if a resource is being (#20580) replaced because the instance was tainted.
2019-03-06 01:18:55 +01:00
# test_instance.foo is tainted, so must be replaced
backend/local: Render CBD replacement (+/-) correctly (#19642) * backend/local: Render CBD replacement (+/-) correctly * command/format: Use IsReplace helper function
2018-12-14 14:45:47 +01:00
+/- resource "test_instance" "foo" {
command: Add experimental concise diff renderer When rendering a diff between current state and projected state, we only show resources and outputs which have changes. However, we show a full structural diff for these values, which includes all attributes and blocks for a changed resource or output. The result can be a very long diff, which makes it difficult to verify what the changed fields are. This commit adds an experimental concise diff renderer, which suppresses most unchanged fields, only displaying the most relevant changes and some identifying context. This means: - Always show all identifying attributes, initially defined as `id`, `name`, and `tags`, even if unchanged; - Only show changed, added, or removed primitive values: `string`, `number`, or `bool`; - Only show added or removed elements in unordered collections and structural types: `map`, `set`, and `object`; - Show added or removed elements with any surrounding unchanged elements for sequence types: `list` and `tuple`; - Only show added or removed nested blocks, or blocks with changed attributes. If any attributes, collection elements, or blocks are hidden, a count is kept and displayed at the end of the parent scope. This ensures that it is clear that the diff is only displaying a subset of the resource. The experiment is currently enabled by default, but can be disabled by setting the TF_X_CONCISE_DIFF environment variable to 0.
2020-08-19 22:47:56 +02:00
# (1 unchanged attribute hidden)
backend/local: Render CBD replacement (+/-) correctly (#19642) * backend/local: Render CBD replacement (+/-) correctly * command/format: Use IsReplace helper function
2018-12-14 14:45:47 +01:00
command: Add experimental concise diff renderer When rendering a diff between current state and projected state, we only show resources and outputs which have changes. However, we show a full structural diff for these values, which includes all attributes and blocks for a changed resource or output. The result can be a very long diff, which makes it difficult to verify what the changed fields are. This commit adds an experimental concise diff renderer, which suppresses most unchanged fields, only displaying the most relevant changes and some identifying context. This means: - Always show all identifying attributes, initially defined as `id`, `name`, and `tags`, even if unchanged; - Only show changed, added, or removed primitive values: `string`, `number`, or `bool`; - Only show added or removed elements in unordered collections and structural types: `map`, `set`, and `object`; - Show added or removed elements with any surrounding unchanged elements for sequence types: `list` and `tuple`; - Only show added or removed nested blocks, or blocks with changed attributes. If any attributes, collection elements, or blocks are hidden, a count is kept and displayed at the end of the parent scope. This ensures that it is clear that the diff is only displaying a subset of the resource. The experiment is currently enabled by default, but can be disabled by setting the TF_X_CONCISE_DIFF environment variable to 0.
2020-08-19 22:47:56 +02:00
# (1 unchanged block hidden)
backend/local: Render CBD replacement (+/-) correctly (#19642) * backend/local: Render CBD replacement (+/-) correctly * command/format: Use IsReplace helper function
2018-12-14 14:45:47 +01:00
}
Plan: 1 to add, 0 to change, 1 to destroy.`
output := b.CLI.(*cli.MockUi).OutputWriter.String()
if !strings.Contains(output, expectedOutput) {
t.Fatalf("Unexpected output:\n%s", output)
}
}
backend/local The local backend implementation is an implementation of backend.Enhanced that recreates all the behavior of the CLI but through the backend interface.
2017-01-19 05:47:56 +01:00
func TestLocal_planRefreshFalse(t *testing.T) {
cleanup temp files from backend tests
2018-03-28 16:54:08 +02:00
b, cleanup := TestLocal(t)
defer cleanup()
backend/local: more tests passing I have no confidence in the change to plans/planfile/tfplan.go. The tests were passing an empty backend config, which planfile was able to write to a file but not read from the same file. This change let me move past that and it did not break any tests in the planfile package, but I am concerned that it introduces undesired behavior.
2018-10-04 23:37:14 +02:00
p := TestLocalProvider(t, b, "test", planFixtureSchema())
backend/local tests tests tests converted the existing testPlanState() from terraform.State to states.State to fix various plan tests. reverted the "bandaid" in plans/planfile/tfplan.go - at this moment the backend tests do not include backend configuration, and so the planfile package can write the plan file but not read it back in. That will be revisted in a separate track of work.
2018-10-09 00:22:59 +02:00
testStateFile(t, b.StatePath, testPlanState())
backend/local The local backend implementation is an implementation of backend.Enhanced that recreates all the behavior of the CLI but through the backend interface.
2017-01-19 05:47:56 +01:00
Standardise directory name for test data
2019-06-30 09:38:36 +02:00
op, configCleanup := testOperationPlan(t, "./testdata/plan")
backend: Update interface and implementations for new config loader The new config loader requires some steps to happen in a different order, particularly in regard to knowing the schema in order to decode the configuration. Here we lean directly on the configschema package, rather than on helper/schema.Backend as before, because it's generally sufficient for our needs here and this prepares us for the helper/schema package later moving out into its own repository to seed a "plugin SDK".
2018-03-21 02:43:02 +01:00
defer configCleanup()
backend/local The local backend implementation is an implementation of backend.Enhanced that recreates all the behavior of the CLI but through the backend interface.
2017-01-19 05:47:56 +01:00
run, err := b.Operation(context.Background(), op)
if err != nil {
t.Fatalf("bad: %s", err)
}
<-run.Done()
backend: Update interface and implementations for new config loader The new config loader requires some steps to happen in a different order, particularly in regard to knowing the schema in order to decode the configuration. Here we lean directly on the configschema package, rather than on helper/schema.Backend as before, because it's generally sufficient for our needs here and this prepares us for the helper/schema package later moving out into its own repository to seed a "plugin SDK".
2018-03-21 02:43:02 +01:00
if run.Result != backend.OperationSuccess {
t.Fatalf("plan operation failed")
backend/local The local backend implementation is an implementation of backend.Enhanced that recreates all the behavior of the CLI but through the backend interface.
2017-01-19 05:47:56 +01:00
}
backend/local WIP commit - fixing tests
2018-09-28 23:04:57 +02:00
if p.ReadResourceCalled {
t.Fatal("ReadResource should not be called")
backend/local The local backend implementation is an implementation of backend.Enhanced that recreates all the behavior of the CLI but through the backend interface.
2017-01-19 05:47:56 +01:00
}
if !run.PlanEmpty {
t.Fatal("plan should be empty")
}
}
func TestLocal_planDestroy(t *testing.T) {
cleanup temp files from backend tests
2018-03-28 16:54:08 +02:00
b, cleanup := TestLocal(t)
defer cleanup()
backend/local: more tests passing I have no confidence in the change to plans/planfile/tfplan.go. The tests were passing an empty backend config, which planfile was able to write to a file but not read from the same file. This change let me move past that and it did not break any tests in the planfile package, but I am concerned that it introduces undesired behavior.
2018-10-04 23:37:14 +02:00
refresh is expected for destroy These tests were not previously running a refresh, and hence did not expect the resources to be read.
2021-01-05 00:27:08 +01:00
TestLocalProvider(t, b, "test", planFixtureSchema())
backend/local tests tests tests converted the existing testPlanState() from terraform.State to states.State to fix various plan tests. reverted the "bandaid" in plans/planfile/tfplan.go - at this moment the backend tests do not include backend configuration, and so the planfile package can write the plan file but not read it back in. That will be revisted in a separate track of work.
2018-10-09 00:22:59 +02:00
testStateFile(t, b.StatePath, testPlanState())
backend/local The local backend implementation is an implementation of backend.Enhanced that recreates all the behavior of the CLI but through the backend interface.
2017-01-19 05:47:56 +01:00
outDir := testTempDir(t)
defer os.RemoveAll(outDir)
planPath := filepath.Join(outDir, "plan.tfplan")
Standardise directory name for test data
2019-06-30 09:38:36 +02:00
op, configCleanup := testOperationPlan(t, "./testdata/plan")
backend: Update interface and implementations for new config loader The new config loader requires some steps to happen in a different order, particularly in regard to knowing the schema in order to decode the configuration. Here we lean directly on the configschema package, rather than on helper/schema.Backend as before, because it's generally sufficient for our needs here and this prepares us for the helper/schema package later moving out into its own repository to seed a "plugin SDK".
2018-03-21 02:43:02 +01:00
defer configCleanup()
backend/local: more tests passing I have no confidence in the change to plans/planfile/tfplan.go. The tests were passing an empty backend config, which planfile was able to write to a file but not read from the same file. This change let me move past that and it did not break any tests in the planfile package, but I am concerned that it introduces undesired behavior.
2018-10-04 23:37:14 +02:00
op.Destroy = true
backend/local The local backend implementation is an implementation of backend.Enhanced that recreates all the behavior of the CLI but through the backend interface.
2017-01-19 05:47:56 +01:00
op.PlanRefresh = true
op.PlanOutPath = planPath
backend/local: Require caller to set PlanOutBackend with PlanOutPath We can't generate a valid plan file without a backend configuration to write into it, but it's the responsibility of the caller (the command package) to manage the backend configuration mechanism, so we require it to tell us what to write here. This feels a little strange because the backend in principle knows its own config, but in practice the backend only knows the _processed_ version of the config, not the raw configuration value that was used to configure it.
2018-10-09 21:19:24 +02:00
cfg := cty.ObjectVal(map[string]cty.Value{
"path": cty.StringVal(b.StatePath),
})
cfgRaw, err := plans.NewDynamicValue(cfg, cfg.Type())
if err != nil {
t.Fatal(err)
}
op.PlanOutBackend = &plans.Backend{
// Just a placeholder so that we can generate a valid plan file.
backend/local: Stub out remaining planfile todos with errors This is just to make sure they show up later when we are working on the tests, so we can be sure not to forget to address them.
2018-10-10 01:32:09 +02:00
Type: "local",
backend/local: Require caller to set PlanOutBackend with PlanOutPath We can't generate a valid plan file without a backend configuration to write into it, but it's the responsibility of the caller (the command package) to manage the backend configuration mechanism, so we require it to tell us what to write here. This feels a little strange because the backend in principle knows its own config, but in practice the backend only knows the _processed_ version of the config, not the raw configuration value that was used to configure it.
2018-10-09 21:19:24 +02:00
Config: cfgRaw,
}
backend/local The local backend implementation is an implementation of backend.Enhanced that recreates all the behavior of the CLI but through the backend interface.
2017-01-19 05:47:56 +01:00
run, err := b.Operation(context.Background(), op)
if err != nil {
t.Fatalf("bad: %s", err)
}
<-run.Done()
backend: Update interface and implementations for new config loader The new config loader requires some steps to happen in a different order, particularly in regard to knowing the schema in order to decode the configuration. Here we lean directly on the configschema package, rather than on helper/schema.Backend as before, because it's generally sufficient for our needs here and this prepares us for the helper/schema package later moving out into its own repository to seed a "plugin SDK".
2018-03-21 02:43:02 +01:00
if run.Result != backend.OperationSuccess {
t.Fatalf("plan operation failed")
backend/local The local backend implementation is an implementation of backend.Enhanced that recreates all the behavior of the CLI but through the backend interface.
2017-01-19 05:47:56 +01:00
}
if run.PlanEmpty {
t.Fatal("plan should not be empty")
}
plan := testReadPlan(t, planPath)
backend/local: more tests passing I have no confidence in the change to plans/planfile/tfplan.go. The tests were passing an empty backend config, which planfile was able to write to a file but not read from the same file. This change let me move past that and it did not break any tests in the planfile package, but I am concerned that it introduces undesired behavior.
2018-10-04 23:37:14 +02:00
for _, r := range plan.Changes.Resources {
if r.Action.String() != "Delete" {
t.Fatalf("bad: %#v", r.Action.String())
}
backend/local The local backend implementation is an implementation of backend.Enhanced that recreates all the behavior of the CLI but through the backend interface.
2017-01-19 05:47:56 +01:00
}
}
backend/local: Avoid rendering data sources on destroy
2018-12-12 17:01:18 +01:00
func TestLocal_planDestroy_withDataSources(t *testing.T) {
b, cleanup := TestLocal(t)
defer cleanup()
refresh is expected for destroy These tests were not previously running a refresh, and hence did not expect the resources to be read.
2021-01-05 00:27:08 +01:00
TestLocalProvider(t, b, "test", planFixtureSchema())
backend/local: Avoid rendering data sources on destroy
2018-12-12 17:01:18 +01:00
testStateFile(t, b.StatePath, testPlanState_withDataSource())
b.CLI = cli.NewMockUi()
outDir := testTempDir(t)
defer os.RemoveAll(outDir)
planPath := filepath.Join(outDir, "plan.tfplan")
Standardise directory name for test data
2019-06-30 09:38:36 +02:00
op, configCleanup := testOperationPlan(t, "./testdata/destroy-with-ds")
backend/local: Avoid rendering data sources on destroy
2018-12-12 17:01:18 +01:00
defer configCleanup()
op.Destroy = true
op.PlanRefresh = true
op.PlanOutPath = planPath
cfg := cty.ObjectVal(map[string]cty.Value{
"path": cty.StringVal(b.StatePath),
})
cfgRaw, err := plans.NewDynamicValue(cfg, cfg.Type())
if err != nil {
t.Fatal(err)
}
op.PlanOutBackend = &plans.Backend{
// Just a placeholder so that we can generate a valid plan file.
Type: "local",
Config: cfgRaw,
}
run, err := b.Operation(context.Background(), op)
if err != nil {
t.Fatalf("bad: %s", err)
}
<-run.Done()
if run.Result != backend.OperationSuccess {
t.Fatalf("plan operation failed")
}
if run.PlanEmpty {
t.Fatal("plan should not be empty")
}
// Data source should still exist in the the plan file
plan := testReadPlan(t, planPath)
if len(plan.Changes.Resources) != 2 {
t.Fatalf("Expected exactly 1 resource for destruction, %d given: %q",
len(plan.Changes.Resources), getAddrs(plan.Changes.Resources))
}
// Data source should not be rendered in the output
expectedOutput := `Terraform will perform the following actions:
fix local backend tests to match new behavior Leaving plan with -refresh=false tests failing for now.
2020-09-11 23:56:12 +02:00
# test_instance.foo[0] will be destroyed
backend/local: Avoid rendering data sources on destroy
2018-12-12 17:01:18 +01:00
- resource "test_instance" "foo" {
- ami = "bar" -> null
- network_interface {
- description = "Main network interface" -> null
- device_index = 0 -> null
}
}
Plan: 0 to add, 0 to change, 1 to destroy.`
output := b.CLI.(*cli.MockUi).OutputWriter.String()
if !strings.Contains(output, expectedOutput) {
fix local backend tests to match new behavior Leaving plan with -refresh=false tests failing for now.
2020-09-11 23:56:12 +02:00
t.Fatalf("Unexpected output:\n%s", output)
backend/local: Avoid rendering data sources on destroy
2018-12-12 17:01:18 +01:00
}
}
func getAddrs(resources []*plans.ResourceInstanceChangeSrc) []string {
unused
2020-12-01 15:06:56 +01:00
addrs := make([]string, len(resources))
backend/local: Avoid rendering data sources on destroy
2018-12-12 17:01:18 +01:00
for i, r := range resources {
addrs[i] = r.Addr.String()
}
return addrs
}
backend/local The local backend implementation is an implementation of backend.Enhanced that recreates all the behavior of the CLI but through the backend interface.
2017-01-19 05:47:56 +01:00
func TestLocal_planOutPathNoChange(t *testing.T) {
cleanup temp files from backend tests
2018-03-28 16:54:08 +02:00
b, cleanup := TestLocal(t)
defer cleanup()
backend/local: Update tests for changes in "terraform" package This mainly consists of adding schema information to the mock providers.
2018-05-23 04:57:04 +02:00
TestLocalProvider(t, b, "test", planFixtureSchema())
backend/local tests tests tests converted the existing testPlanState() from terraform.State to states.State to fix various plan tests. reverted the "bandaid" in plans/planfile/tfplan.go - at this moment the backend tests do not include backend configuration, and so the planfile package can write the plan file but not read it back in. That will be revisted in a separate track of work.
2018-10-09 00:22:59 +02:00
testStateFile(t, b.StatePath, testPlanState())
backend/local The local backend implementation is an implementation of backend.Enhanced that recreates all the behavior of the CLI but through the backend interface.
2017-01-19 05:47:56 +01:00
outDir := testTempDir(t)
defer os.RemoveAll(outDir)
planPath := filepath.Join(outDir, "plan.tfplan")
Standardise directory name for test data
2019-06-30 09:38:36 +02:00
op, configCleanup := testOperationPlan(t, "./testdata/plan")
backend: Update interface and implementations for new config loader The new config loader requires some steps to happen in a different order, particularly in regard to knowing the schema in order to decode the configuration. Here we lean directly on the configschema package, rather than on helper/schema.Backend as before, because it's generally sufficient for our needs here and this prepares us for the helper/schema package later moving out into its own repository to seed a "plugin SDK".
2018-03-21 02:43:02 +01:00
defer configCleanup()
backend/local The local backend implementation is an implementation of backend.Enhanced that recreates all the behavior of the CLI but through the backend interface.
2017-01-19 05:47:56 +01:00
op.PlanOutPath = planPath
backend/local: Require caller to set PlanOutBackend with PlanOutPath We can't generate a valid plan file without a backend configuration to write into it, but it's the responsibility of the caller (the command package) to manage the backend configuration mechanism, so we require it to tell us what to write here. This feels a little strange because the backend in principle knows its own config, but in practice the backend only knows the _processed_ version of the config, not the raw configuration value that was used to configure it.
2018-10-09 21:19:24 +02:00
cfg := cty.ObjectVal(map[string]cty.Value{
"path": cty.StringVal(b.StatePath),
})
cfgRaw, err := plans.NewDynamicValue(cfg, cfg.Type())
if err != nil {
t.Fatal(err)
}
op.PlanOutBackend = &plans.Backend{
// Just a placeholder so that we can generate a valid plan file.
backend/local: Stub out remaining planfile todos with errors This is just to make sure they show up later when we are working on the tests, so we can be sure not to forget to address them.
2018-10-10 01:32:09 +02:00
Type: "local",
backend/local: Require caller to set PlanOutBackend with PlanOutPath We can't generate a valid plan file without a backend configuration to write into it, but it's the responsibility of the caller (the command package) to manage the backend configuration mechanism, so we require it to tell us what to write here. This feels a little strange because the backend in principle knows its own config, but in practice the backend only knows the _processed_ version of the config, not the raw configuration value that was used to configure it.
2018-10-09 21:19:24 +02:00
Config: cfgRaw,
}
insert PlanRefresh into the context
2020-09-23 17:09:42 +02:00
op.PlanRefresh = true
backend/local The local backend implementation is an implementation of backend.Enhanced that recreates all the behavior of the CLI but through the backend interface.
2017-01-19 05:47:56 +01:00
run, err := b.Operation(context.Background(), op)
if err != nil {
t.Fatalf("bad: %s", err)
}
<-run.Done()
backend: Update interface and implementations for new config loader The new config loader requires some steps to happen in a different order, particularly in regard to knowing the schema in order to decode the configuration. Here we lean directly on the configschema package, rather than on helper/schema.Backend as before, because it's generally sufficient for our needs here and this prepares us for the helper/schema package later moving out into its own repository to seed a "plugin SDK".
2018-03-21 02:43:02 +01:00
if run.Result != backend.OperationSuccess {
t.Fatalf("plan operation failed")
backend/local The local backend implementation is an implementation of backend.Enhanced that recreates all the behavior of the CLI but through the backend interface.
2017-01-19 05:47:56 +01:00
}
plan := testReadPlan(t, planPath)
backend/local tests tests tests converted the existing testPlanState() from terraform.State to states.State to fix various plan tests. reverted the "bandaid" in plans/planfile/tfplan.go - at this moment the backend tests do not include backend configuration, and so the planfile package can write the plan file but not read it back in. That will be revisted in a separate track of work.
2018-10-09 00:22:59 +02:00
if !plan.Changes.Empty() {
t.Fatalf("expected empty plan to be written")
backend/local The local backend implementation is an implementation of backend.Enhanced that recreates all the behavior of the CLI but through the backend interface.
2017-01-19 05:47:56 +01:00
}
}
backend: Update interface and implementations for new config loader The new config loader requires some steps to happen in a different order, particularly in regard to knowing the schema in order to decode the configuration. Here we lean directly on the configschema package, rather than on helper/schema.Backend as before, because it's generally sufficient for our needs here and this prepares us for the helper/schema package later moving out into its own repository to seed a "plugin SDK".
2018-03-21 02:43:02 +01:00
func testOperationPlan(t *testing.T, configDir string) (*backend.Operation, func()) {
t.Helper()
Move module install functionality over to internal/initwd
2019-01-09 03:39:14 +01:00
_, configLoader, configCleanup := initwd.MustLoadConfigForTests(t, configDir)
backend: Update interface and implementations for new config loader The new config loader requires some steps to happen in a different order, particularly in regard to knowing the schema in order to decode the configuration. Here we lean directly on the configschema package, rather than on helper/schema.Backend as before, because it's generally sufficient for our needs here and this prepares us for the helper/schema package later moving out into its own repository to seed a "plugin SDK".
2018-03-21 02:43:02 +01:00
backend/local The local backend implementation is an implementation of backend.Enhanced that recreates all the behavior of the CLI but through the backend interface.
2017-01-19 05:47:56 +01:00
return &backend.Operation{
backend: Update interface and implementations for new config loader The new config loader requires some steps to happen in a different order, particularly in regard to knowing the schema in order to decode the configuration. Here we lean directly on the configschema package, rather than on helper/schema.Backend as before, because it's generally sufficient for our needs here and this prepares us for the helper/schema package later moving out into its own repository to seed a "plugin SDK".
2018-03-21 02:43:02 +01:00
Type: backend.OperationTypePlan,
ConfigDir: configDir,
ConfigLoader: configLoader,
}, configCleanup
backend/local The local backend implementation is an implementation of backend.Enhanced that recreates all the behavior of the CLI but through the backend interface.
2017-01-19 05:47:56 +01:00
}
backend/local tests tests tests converted the existing testPlanState() from terraform.State to states.State to fix various plan tests. reverted the "bandaid" in plans/planfile/tfplan.go - at this moment the backend tests do not include backend configuration, and so the planfile package can write the plan file but not read it back in. That will be revisted in a separate track of work.
2018-10-09 00:22:59 +02:00
// testPlanState is just a common state that we use for testing plan.
func testPlanState() *states.State {
state := states.NewState()
rootModule := state.RootModule()
rootModule.SetResourceInstanceCurrent(
addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test_instance",
Name: "foo",
}.Instance(addrs.IntKey(0)),
&states.ResourceInstanceObjectSrc{
core: Automatically upgrade resource instance states on read If an instance object in state has an earlier schema version number then it is likely that the schema we're holding won't be able to decode the raw data that is stored. Instead, we must ask the provider to upgrade it for us first, which might also include translating it from flatmap form if it was last updated with a Terraform version earlier than v0.12. This ends up being a "seam" between our use of int64 for schema versions in the providers package and uint64 everywhere else. We intend to standardize on int64 everywhere eventually, but for now this remains consistent with existing usage in each layer to keep the type conversion noise contained here and avoid mass-updates to other Terraform components at this time. This also includes a minor change to the test helpers for the backend/local package, which were inexplicably setting a SchemaVersion of 1 on the basic test state but setting the mock schema version to zero, creating an invalid situation where the state would need to be downgraded.
2018-11-30 19:56:50 +01:00
Status: states.ObjectReady,
backend/local tests tests tests converted the existing testPlanState() from terraform.State to states.State to fix various plan tests. reverted the "bandaid" in plans/planfile/tfplan.go - at this moment the backend tests do not include backend configuration, and so the planfile package can write the plan file but not read it back in. That will be revisted in a separate track of work.
2018-10-09 00:22:59 +02:00
AttrsJSON: []byte(`{
"ami": "bar",
"network_interface": [{
"device_index": 0,
"description": "Main network interface"
}]
}`),
backend/local The local backend implementation is an implementation of backend.Enhanced that recreates all the behavior of the CLI but through the backend interface.
2017-01-19 05:47:56 +01:00
},
addrs: embed Provider in AbsProviderConfig instead of Type a large refactor to addrs.AbsProviderConfig, embedding the addrs.Provider instead of a Type string. I've added and updated tests, added some Legacy functions to support older state formats and shims, and added a normalization step when reading v4 (current) state files (not the added tests under states/statefile/roundtrip which work with both current and legacy-style AbsProviderConfig strings). The remaining 'fixme' and 'todo' comments are mostly going to be addressed in a subsequent PR and involve looking up a given local provider config's FQN. This is fine for now as we are only working with default assumption.
2020-02-13 21:32:58 +01:00
addrs.AbsProviderConfig{
backend/local: refactor tests with modern state and default providers (#24524)
2020-04-01 21:07:05 +02:00
Provider: addrs.NewDefaultProvider("test"),
finish provider ModuleInstance replacement
2020-03-11 19:19:52 +01:00
Module: addrs.RootModule,
addrs: embed Provider in AbsProviderConfig instead of Type a large refactor to addrs.AbsProviderConfig, embedding the addrs.Provider instead of a Type string. I've added and updated tests, added some Legacy functions to support older state formats and shims, and added a normalization step when reading v4 (current) state files (not the added tests under states/statefile/roundtrip which work with both current and legacy-style AbsProviderConfig strings). The remaining 'fixme' and 'todo' comments are mostly going to be addressed in a subsequent PR and involve looking up a given local provider config's FQN. This is fine for now as we are only working with default assumption.
2020-02-13 21:32:58 +01:00
},
backend/local tests tests tests converted the existing testPlanState() from terraform.State to states.State to fix various plan tests. reverted the "bandaid" in plans/planfile/tfplan.go - at this moment the backend tests do not include backend configuration, and so the planfile package can write the plan file but not read it back in. That will be revisted in a separate track of work.
2018-10-09 00:22:59 +02:00
)
return state
backend/local The local backend implementation is an implementation of backend.Enhanced that recreates all the behavior of the CLI but through the backend interface.
2017-01-19 05:47:56 +01:00
}
backend/local: Avoid rendering data sources on destroy
2018-12-12 17:01:18 +01:00
func testPlanState_withDataSource() *states.State {
state := states.NewState()
rootModule := state.RootModule()
rootModule.SetResourceInstanceCurrent(
addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test_instance",
Name: "foo",
}.Instance(addrs.IntKey(0)),
&states.ResourceInstanceObjectSrc{
Status: states.ObjectReady,
AttrsJSON: []byte(`{
"ami": "bar",
"network_interface": [{
"device_index": 0,
"description": "Main network interface"
}]
}`),
},
addrs: embed Provider in AbsProviderConfig instead of Type a large refactor to addrs.AbsProviderConfig, embedding the addrs.Provider instead of a Type string. I've added and updated tests, added some Legacy functions to support older state formats and shims, and added a normalization step when reading v4 (current) state files (not the added tests under states/statefile/roundtrip which work with both current and legacy-style AbsProviderConfig strings). The remaining 'fixme' and 'todo' comments are mostly going to be addressed in a subsequent PR and involve looking up a given local provider config's FQN. This is fine for now as we are only working with default assumption.
2020-02-13 21:32:58 +01:00
addrs.AbsProviderConfig{
backend/local: refactor tests with modern state and default providers (#24524)
2020-04-01 21:07:05 +02:00
Provider: addrs.NewDefaultProvider("test"),
finish provider ModuleInstance replacement
2020-03-11 19:19:52 +01:00
Module: addrs.RootModule,
addrs: embed Provider in AbsProviderConfig instead of Type a large refactor to addrs.AbsProviderConfig, embedding the addrs.Provider instead of a Type string. I've added and updated tests, added some Legacy functions to support older state formats and shims, and added a normalization step when reading v4 (current) state files (not the added tests under states/statefile/roundtrip which work with both current and legacy-style AbsProviderConfig strings). The remaining 'fixme' and 'todo' comments are mostly going to be addressed in a subsequent PR and involve looking up a given local provider config's FQN. This is fine for now as we are only working with default assumption.
2020-02-13 21:32:58 +01:00
},
backend/local: Avoid rendering data sources on destroy
2018-12-12 17:01:18 +01:00
)
rootModule.SetResourceInstanceCurrent(
addrs.Resource{
Mode: addrs.DataResourceMode,
Type: "test_ds",
Name: "bar",
}.Instance(addrs.IntKey(0)),
&states.ResourceInstanceObjectSrc{
Status: states.ObjectReady,
AttrsJSON: []byte(`{
"filter": "foo"
}`),
},
addrs: embed Provider in AbsProviderConfig instead of Type a large refactor to addrs.AbsProviderConfig, embedding the addrs.Provider instead of a Type string. I've added and updated tests, added some Legacy functions to support older state formats and shims, and added a normalization step when reading v4 (current) state files (not the added tests under states/statefile/roundtrip which work with both current and legacy-style AbsProviderConfig strings). The remaining 'fixme' and 'todo' comments are mostly going to be addressed in a subsequent PR and involve looking up a given local provider config's FQN. This is fine for now as we are only working with default assumption.
2020-02-13 21:32:58 +01:00
addrs.AbsProviderConfig{
backend/local: refactor tests with modern state and default providers (#24524)
2020-04-01 21:07:05 +02:00
Provider: addrs.NewDefaultProvider("test"),
finish provider ModuleInstance replacement
2020-03-11 19:19:52 +01:00
Module: addrs.RootModule,
addrs: embed Provider in AbsProviderConfig instead of Type a large refactor to addrs.AbsProviderConfig, embedding the addrs.Provider instead of a Type string. I've added and updated tests, added some Legacy functions to support older state formats and shims, and added a normalization step when reading v4 (current) state files (not the added tests under states/statefile/roundtrip which work with both current and legacy-style AbsProviderConfig strings). The remaining 'fixme' and 'todo' comments are mostly going to be addressed in a subsequent PR and involve looking up a given local provider config's FQN. This is fine for now as we are only working with default assumption.
2020-02-13 21:32:58 +01:00
},
backend/local: Avoid rendering data sources on destroy
2018-12-12 17:01:18 +01:00
)
return state
}
backend/local: Render CBD replacement (+/-) correctly (#19642) * backend/local: Render CBD replacement (+/-) correctly * command/format: Use IsReplace helper function
2018-12-14 14:45:47 +01:00
func testPlanState_tainted() *states.State {
state := states.NewState()
rootModule := state.RootModule()
rootModule.SetResourceInstanceCurrent(
addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test_instance",
Name: "foo",
wrong instance key in test state This was never picked up by the tests until now
2020-09-16 19:56:08 +02:00
}.Instance(addrs.NoKey),
backend/local: Render CBD replacement (+/-) correctly (#19642) * backend/local: Render CBD replacement (+/-) correctly * command/format: Use IsReplace helper function
2018-12-14 14:45:47 +01:00
&states.ResourceInstanceObjectSrc{
Status: states.ObjectTainted,
AttrsJSON: []byte(`{
"ami": "bar",
"network_interface": [{
"device_index": 0,
"description": "Main network interface"
}]
}`),
},
addrs: embed Provider in AbsProviderConfig instead of Type a large refactor to addrs.AbsProviderConfig, embedding the addrs.Provider instead of a Type string. I've added and updated tests, added some Legacy functions to support older state formats and shims, and added a normalization step when reading v4 (current) state files (not the added tests under states/statefile/roundtrip which work with both current and legacy-style AbsProviderConfig strings). The remaining 'fixme' and 'todo' comments are mostly going to be addressed in a subsequent PR and involve looking up a given local provider config's FQN. This is fine for now as we are only working with default assumption.
2020-02-13 21:32:58 +01:00
addrs.AbsProviderConfig{
backend/local: refactor tests with modern state and default providers (#24524)
2020-04-01 21:07:05 +02:00
Provider: addrs.NewDefaultProvider("test"),
finish provider ModuleInstance replacement
2020-03-11 19:19:52 +01:00
Module: addrs.RootModule,
addrs: embed Provider in AbsProviderConfig instead of Type a large refactor to addrs.AbsProviderConfig, embedding the addrs.Provider instead of a Type string. I've added and updated tests, added some Legacy functions to support older state formats and shims, and added a normalization step when reading v4 (current) state files (not the added tests under states/statefile/roundtrip which work with both current and legacy-style AbsProviderConfig strings). The remaining 'fixme' and 'todo' comments are mostly going to be addressed in a subsequent PR and involve looking up a given local provider config's FQN. This is fine for now as we are only working with default assumption.
2020-02-13 21:32:58 +01:00
},
backend/local: Render CBD replacement (+/-) correctly (#19642) * backend/local: Render CBD replacement (+/-) correctly * command/format: Use IsReplace helper function
2018-12-14 14:45:47 +01:00
)
return state
}
plans/objchange: further harden ProposedNewObject against ~weird~ incoming values Addresses an odd state where the priorV of an object to be changed is known but null. While this situation should not happen, it seemed prudent to ensure that core is resilient to providers sending incorrect values (which might also occur with manually edited state).
2018-09-29 00:57:27 +02:00
func testReadPlan(t *testing.T, path string) *plans.Plan {
backend/local: Require caller to set PlanOutBackend with PlanOutPath We can't generate a valid plan file without a backend configuration to write into it, but it's the responsibility of the caller (the command package) to manage the backend configuration mechanism, so we require it to tell us what to write here. This feels a little strange because the backend in principle knows its own config, but in practice the backend only knows the _processed_ version of the config, not the raw configuration value that was used to configure it.
2018-10-09 21:19:24 +02:00
t.Helper()
plans/objchange: further harden ProposedNewObject against ~weird~ incoming values Addresses an odd state where the priorV of an object to be changed is known but null. While this situation should not happen, it seemed prudent to ensure that core is resilient to providers sending incorrect values (which might also occur with manually edited state).
2018-09-29 00:57:27 +02:00
p, err := planfile.Open(path)
backend/local The local backend implementation is an implementation of backend.Enhanced that recreates all the behavior of the CLI but through the backend interface.
2017-01-19 05:47:56 +01:00
if err != nil {
t.Fatalf("err: %s", err)
}
plans/objchange: further harden ProposedNewObject against ~weird~ incoming values Addresses an odd state where the priorV of an object to be changed is known but null. While this situation should not happen, it seemed prudent to ensure that core is resilient to providers sending incorrect values (which might also occur with manually edited state).
2018-09-29 00:57:27 +02:00
defer p.Close()
backend/local The local backend implementation is an implementation of backend.Enhanced that recreates all the behavior of the CLI but through the backend interface.
2017-01-19 05:47:56 +01:00
plans/objchange: further harden ProposedNewObject against ~weird~ incoming values Addresses an odd state where the priorV of an object to be changed is known but null. While this situation should not happen, it seemed prudent to ensure that core is resilient to providers sending incorrect values (which might also occur with manually edited state).
2018-09-29 00:57:27 +02:00
plan, err := p.ReadPlan()
backend/local: more tests passing I have no confidence in the change to plans/planfile/tfplan.go. The tests were passing an empty backend config, which planfile was able to write to a file but not read from the same file. This change let me move past that and it did not break any tests in the planfile package, but I am concerned that it introduces undesired behavior.
2018-10-04 23:37:14 +02:00
if err != nil {
t.Fatalf("err: %s", err)
}
backend/local The local backend implementation is an implementation of backend.Enhanced that recreates all the behavior of the CLI but through the backend interface.
2017-01-19 05:47:56 +01:00
plans/objchange: further harden ProposedNewObject against ~weird~ incoming values Addresses an odd state where the priorV of an object to be changed is known but null. While this situation should not happen, it seemed prudent to ensure that core is resilient to providers sending incorrect values (which might also occur with manually edited state).
2018-09-29 00:57:27 +02:00
return plan
backend/local The local backend implementation is an implementation of backend.Enhanced that recreates all the behavior of the CLI but through the backend interface.
2017-01-19 05:47:56 +01:00
}
backend/local: Update tests for changes in "terraform" package This mainly consists of adding schema information to the mock providers.
2018-05-23 04:57:04 +02:00
// planFixtureSchema returns a schema suitable for processing the
Standardise directory name for test data
2019-06-30 09:38:36 +02:00
// configuration in testdata/plan . This schema should be
backend/local: Update tests for changes in "terraform" package This mainly consists of adding schema information to the mock providers.
2018-05-23 04:57:04 +02:00
// assigned to a mock provider named "test".
func planFixtureSchema() *terraform.ProviderSchema {
return &terraform.ProviderSchema{
ResourceTypes: map[string]*configschema.Block{
"test_instance": {
Attributes: map[string]*configschema.Attribute{
"ami": {Type: cty.String, Optional: true},
},
BlockTypes: map[string]*configschema.NestedBlock{
"network_interface": {
Nesting: configschema.NestingList,
Block: configschema.Block{
Attributes: map[string]*configschema.Attribute{
"device_index": {Type: cty.Number, Optional: true},
"description": {Type: cty.String, Optional: true},
},
},
},
},
},
},
backend/local: Avoid rendering data sources on destroy
2018-12-12 17:01:18 +01:00
DataSources: map[string]*configschema.Block{
"test_ds": {
Attributes: map[string]*configschema.Attribute{
"filter": {Type: cty.String, Required: true},
},
},
},
backend/local: Update tests for changes in "terraform" package This mainly consists of adding schema information to the mock providers.
2018-05-23 04:57:04 +02:00
}
}