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

920 lines
26 KiB
Go
Raw Normal View History

backend/local: Replace CLI with view instance This commit extracts the remaining UI logic from the local backend, and removes access to the direct CLI output. This is replaced with an instance of a `views.Operation` interface, which codifies the current requirements for the local backend to interact with the user. The exception to this at present is interactivity: approving a plan still depends on the `UIIn` field for the backend. This is out of scope for this commit and can be revisited separately, at which time the `UIOut` field can also be removed. Changes in support of this: - Some instances of direct error output have been replaced with diagnostics, most notably in the emergency state backup handler. This requires reformatting the error messages to allow the diagnostic renderer to line-wrap them; - The "in-automation" logic has moved out of the backend and into the view implementation; - The plan, apply, refresh, and import commands instantiate a view and set it on the `backend.Operation` struct, as these are the only code paths which call the `local.Operation()` method that requires it; - The show command requires the plan rendering code which is now in the views package, so there is a stub implementation of a `views.Show` interface there. Other refactoring work in support of migrating these commands to the common views code structure will come in follow-up PRs, at which point we will be able to remove the UI instances from the unit tests for those commands.
2021-02-17 19:01:30 +01:00
package views
import (
cli: Add JSON logs for operations commands
2021-02-23 16:16:09 +01:00
"bytes"
backend/local: Replace CLI with view instance This commit extracts the remaining UI logic from the local backend, and removes access to the direct CLI output. This is replaced with an instance of a `views.Operation` interface, which codifies the current requirements for the local backend to interact with the user. The exception to this at present is interactivity: approving a plan still depends on the `UIIn` field for the backend. This is out of scope for this commit and can be revisited separately, at which time the `UIOut` field can also be removed. Changes in support of this: - Some instances of direct error output have been replaced with diagnostics, most notably in the emergency state backup handler. This requires reformatting the error messages to allow the diagnostic renderer to line-wrap them; - The "in-automation" logic has moved out of the backend and into the view implementation; - The plan, apply, refresh, and import commands instantiate a view and set it on the `backend.Operation` struct, as these are the only code paths which call the `local.Operation()` method that requires it; - The show command requires the plan rendering code which is now in the views package, so there is a stub implementation of a `views.Show` interface there. Other refactoring work in support of migrating these commands to the common views code structure will come in follow-up PRs, at which point we will be able to remove the UI instances from the unit tests for those commands.
2021-02-17 19:01:30 +01:00
"encoding/json"
"strings"
"testing"
Move addrs/ to internal/addrs/ This is part of a general effort to move all of Terraform's non-library package surface under internal in order to reinforce that these are for internal use within Terraform only. If you were previously importing packages under this prefix into an external codebase, you could pin to an earlier release tag as an interim solution until you've make a plan to achieve the same functionality some other way.
2021-05-17 21:00:50 +02:00
"github.com/hashicorp/terraform/internal/addrs"
Move command/ to internal/command/ This is part of a general effort to move all of Terraform's non-library package surface under internal in order to reinforce that these are for internal use within Terraform only. If you were previously importing packages under this prefix into an external codebase, you could pin to an earlier release tag as an interim solution until you've make a plan to achieve the same functionality some other way.
2021-05-17 21:07:38 +02:00
"github.com/hashicorp/terraform/internal/command/arguments"
Move plans/ to internal/plans/ This is part of a general effort to move all of Terraform's non-library package surface under internal in order to reinforce that these are for internal use within Terraform only. If you were previously importing packages under this prefix into an external codebase, you could pin to an earlier release tag as an interim solution until you've make a plan to achieve the same functionality some other way.
2021-05-17 21:33:17 +02:00
"github.com/hashicorp/terraform/internal/plans"
Move states/ to internal/states/ This is part of a general effort to move all of Terraform's non-library package surface under internal in order to reinforce that these are for internal use within Terraform only. If you were previously importing packages under this prefix into an external codebase, you could pin to an earlier release tag as an interim solution until you've make a plan to achieve the same functionality some other way.
2021-05-17 21:43:35 +02:00
"github.com/hashicorp/terraform/internal/states"
"github.com/hashicorp/terraform/internal/states/statefile"
backend/local: Replace CLI with view instance This commit extracts the remaining UI logic from the local backend, and removes access to the direct CLI output. This is replaced with an instance of a `views.Operation` interface, which codifies the current requirements for the local backend to interact with the user. The exception to this at present is interactivity: approving a plan still depends on the `UIIn` field for the backend. This is out of scope for this commit and can be revisited separately, at which time the `UIOut` field can also be removed. Changes in support of this: - Some instances of direct error output have been replaced with diagnostics, most notably in the emergency state backup handler. This requires reformatting the error messages to allow the diagnostic renderer to line-wrap them; - The "in-automation" logic has moved out of the backend and into the view implementation; - The plan, apply, refresh, and import commands instantiate a view and set it on the `backend.Operation` struct, as these are the only code paths which call the `local.Operation()` method that requires it; - The show command requires the plan rendering code which is now in the views package, so there is a stub implementation of a `views.Show` interface there. Other refactoring work in support of migrating these commands to the common views code structure will come in follow-up PRs, at which point we will be able to remove the UI instances from the unit tests for those commands.
2021-02-17 19:01:30 +01:00
"github.com/hashicorp/terraform/internal/terminal"
Move terraform/ to internal/terraform/ This is part of a general effort to move all of Terraform's non-library package surface under internal in order to reinforce that these are for internal use within Terraform only. If you were previously importing packages under this prefix into an external codebase, you could pin to an earlier release tag as an interim solution until you've make a plan to achieve the same functionality some other way.
2021-05-17 21:46:19 +02:00
"github.com/hashicorp/terraform/internal/terraform"
backend/local: Replace CLI with view instance This commit extracts the remaining UI logic from the local backend, and removes access to the direct CLI output. This is replaced with an instance of a `views.Operation` interface, which codifies the current requirements for the local backend to interact with the user. The exception to this at present is interactivity: approving a plan still depends on the `UIIn` field for the backend. This is out of scope for this commit and can be revisited separately, at which time the `UIOut` field can also be removed. Changes in support of this: - Some instances of direct error output have been replaced with diagnostics, most notably in the emergency state backup handler. This requires reformatting the error messages to allow the diagnostic renderer to line-wrap them; - The "in-automation" logic has moved out of the backend and into the view implementation; - The plan, apply, refresh, and import commands instantiate a view and set it on the `backend.Operation` struct, as these are the only code paths which call the `local.Operation()` method that requires it; - The show command requires the plan rendering code which is now in the views package, so there is a stub implementation of a `views.Show` interface there. Other refactoring work in support of migrating these commands to the common views code structure will come in follow-up PRs, at which point we will be able to remove the UI instances from the unit tests for those commands.
2021-02-17 19:01:30 +01:00
)
func TestOperation_stopping(t *testing.T) {
streams, done := terminal.StreamsForTesting(t)
v := NewOperation(arguments.ViewHuman, false, NewView(streams))
v.Stopping()
if got, want := done(t).Stdout(), "Stopping operation...\n"; got != want {
t.Errorf("wrong result\ngot: %q\nwant: %q", got, want)
}
}
func TestOperation_cancelled(t *testing.T) {
testCases := map[string]struct {
command+backend: generalized "plan mode" So far we've only had "normal mode" and "destroy mode", where the latter is activated either by "terraform plan -destroy" or "terraform destroy". In preparation for introducing a third mode "refresh only" this generalizes how we handle modes so we can potentially deal with an arbitrary number of modes, although for now we only intend to have three. Mostly this is just a different implementation of the same old behavior, but there is one small user-visible difference here: the "terraform apply" command now accepts a -destroy option, mirroring the option of the same name on "terraform plan", which in turn makes "terraform destroy" effectively a shorthand for "terraform apply -destroy". This is intended to make us consistent that "terraform apply" without a plan file argument accepts all of the same plan-customization options that "terraform plan" does, which will in turn avoid us having to add a new alias of "terraform plan" for each new plan mode we might add. The -help output is changed in that vein here, although we'll wait for subsequent commit to make a similar change to the website documentation just so we can deal with the "refresh only mode" docs at the same time.
2021-04-06 01:28:59 +02:00
planMode plans.Mode
want string
backend/local: Replace CLI with view instance This commit extracts the remaining UI logic from the local backend, and removes access to the direct CLI output. This is replaced with an instance of a `views.Operation` interface, which codifies the current requirements for the local backend to interact with the user. The exception to this at present is interactivity: approving a plan still depends on the `UIIn` field for the backend. This is out of scope for this commit and can be revisited separately, at which time the `UIOut` field can also be removed. Changes in support of this: - Some instances of direct error output have been replaced with diagnostics, most notably in the emergency state backup handler. This requires reformatting the error messages to allow the diagnostic renderer to line-wrap them; - The "in-automation" logic has moved out of the backend and into the view implementation; - The plan, apply, refresh, and import commands instantiate a view and set it on the `backend.Operation` struct, as these are the only code paths which call the `local.Operation()` method that requires it; - The show command requires the plan rendering code which is now in the views package, so there is a stub implementation of a `views.Show` interface there. Other refactoring work in support of migrating these commands to the common views code structure will come in follow-up PRs, at which point we will be able to remove the UI instances from the unit tests for those commands.
2021-02-17 19:01:30 +01:00
}{
"apply": {
command+backend: generalized "plan mode" So far we've only had "normal mode" and "destroy mode", where the latter is activated either by "terraform plan -destroy" or "terraform destroy". In preparation for introducing a third mode "refresh only" this generalizes how we handle modes so we can potentially deal with an arbitrary number of modes, although for now we only intend to have three. Mostly this is just a different implementation of the same old behavior, but there is one small user-visible difference here: the "terraform apply" command now accepts a -destroy option, mirroring the option of the same name on "terraform plan", which in turn makes "terraform destroy" effectively a shorthand for "terraform apply -destroy". This is intended to make us consistent that "terraform apply" without a plan file argument accepts all of the same plan-customization options that "terraform plan" does, which will in turn avoid us having to add a new alias of "terraform plan" for each new plan mode we might add. The -help output is changed in that vein here, although we'll wait for subsequent commit to make a similar change to the website documentation just so we can deal with the "refresh only mode" docs at the same time.
2021-04-06 01:28:59 +02:00
planMode: plans.NormalMode,
want: "Apply cancelled.\n",
backend/local: Replace CLI with view instance This commit extracts the remaining UI logic from the local backend, and removes access to the direct CLI output. This is replaced with an instance of a `views.Operation` interface, which codifies the current requirements for the local backend to interact with the user. The exception to this at present is interactivity: approving a plan still depends on the `UIIn` field for the backend. This is out of scope for this commit and can be revisited separately, at which time the `UIOut` field can also be removed. Changes in support of this: - Some instances of direct error output have been replaced with diagnostics, most notably in the emergency state backup handler. This requires reformatting the error messages to allow the diagnostic renderer to line-wrap them; - The "in-automation" logic has moved out of the backend and into the view implementation; - The plan, apply, refresh, and import commands instantiate a view and set it on the `backend.Operation` struct, as these are the only code paths which call the `local.Operation()` method that requires it; - The show command requires the plan rendering code which is now in the views package, so there is a stub implementation of a `views.Show` interface there. Other refactoring work in support of migrating these commands to the common views code structure will come in follow-up PRs, at which point we will be able to remove the UI instances from the unit tests for those commands.
2021-02-17 19:01:30 +01:00
},
"destroy": {
command+backend: generalized "plan mode" So far we've only had "normal mode" and "destroy mode", where the latter is activated either by "terraform plan -destroy" or "terraform destroy". In preparation for introducing a third mode "refresh only" this generalizes how we handle modes so we can potentially deal with an arbitrary number of modes, although for now we only intend to have three. Mostly this is just a different implementation of the same old behavior, but there is one small user-visible difference here: the "terraform apply" command now accepts a -destroy option, mirroring the option of the same name on "terraform plan", which in turn makes "terraform destroy" effectively a shorthand for "terraform apply -destroy". This is intended to make us consistent that "terraform apply" without a plan file argument accepts all of the same plan-customization options that "terraform plan" does, which will in turn avoid us having to add a new alias of "terraform plan" for each new plan mode we might add. The -help output is changed in that vein here, although we'll wait for subsequent commit to make a similar change to the website documentation just so we can deal with the "refresh only mode" docs at the same time.
2021-04-06 01:28:59 +02:00
planMode: plans.DestroyMode,
want: "Destroy cancelled.\n",
backend/local: Replace CLI with view instance This commit extracts the remaining UI logic from the local backend, and removes access to the direct CLI output. This is replaced with an instance of a `views.Operation` interface, which codifies the current requirements for the local backend to interact with the user. The exception to this at present is interactivity: approving a plan still depends on the `UIIn` field for the backend. This is out of scope for this commit and can be revisited separately, at which time the `UIOut` field can also be removed. Changes in support of this: - Some instances of direct error output have been replaced with diagnostics, most notably in the emergency state backup handler. This requires reformatting the error messages to allow the diagnostic renderer to line-wrap them; - The "in-automation" logic has moved out of the backend and into the view implementation; - The plan, apply, refresh, and import commands instantiate a view and set it on the `backend.Operation` struct, as these are the only code paths which call the `local.Operation()` method that requires it; - The show command requires the plan rendering code which is now in the views package, so there is a stub implementation of a `views.Show` interface there. Other refactoring work in support of migrating these commands to the common views code structure will come in follow-up PRs, at which point we will be able to remove the UI instances from the unit tests for those commands.
2021-02-17 19:01:30 +01:00
},
}
for name, tc := range testCases {
t.Run(name, func(t *testing.T) {
streams, done := terminal.StreamsForTesting(t)
v := NewOperation(arguments.ViewHuman, false, NewView(streams))
command+backend: generalized "plan mode" So far we've only had "normal mode" and "destroy mode", where the latter is activated either by "terraform plan -destroy" or "terraform destroy". In preparation for introducing a third mode "refresh only" this generalizes how we handle modes so we can potentially deal with an arbitrary number of modes, although for now we only intend to have three. Mostly this is just a different implementation of the same old behavior, but there is one small user-visible difference here: the "terraform apply" command now accepts a -destroy option, mirroring the option of the same name on "terraform plan", which in turn makes "terraform destroy" effectively a shorthand for "terraform apply -destroy". This is intended to make us consistent that "terraform apply" without a plan file argument accepts all of the same plan-customization options that "terraform plan" does, which will in turn avoid us having to add a new alias of "terraform plan" for each new plan mode we might add. The -help output is changed in that vein here, although we'll wait for subsequent commit to make a similar change to the website documentation just so we can deal with the "refresh only mode" docs at the same time.
2021-04-06 01:28:59 +02:00
v.Cancelled(tc.planMode)
backend/local: Replace CLI with view instance This commit extracts the remaining UI logic from the local backend, and removes access to the direct CLI output. This is replaced with an instance of a `views.Operation` interface, which codifies the current requirements for the local backend to interact with the user. The exception to this at present is interactivity: approving a plan still depends on the `UIIn` field for the backend. This is out of scope for this commit and can be revisited separately, at which time the `UIOut` field can also be removed. Changes in support of this: - Some instances of direct error output have been replaced with diagnostics, most notably in the emergency state backup handler. This requires reformatting the error messages to allow the diagnostic renderer to line-wrap them; - The "in-automation" logic has moved out of the backend and into the view implementation; - The plan, apply, refresh, and import commands instantiate a view and set it on the `backend.Operation` struct, as these are the only code paths which call the `local.Operation()` method that requires it; - The show command requires the plan rendering code which is now in the views package, so there is a stub implementation of a `views.Show` interface there. Other refactoring work in support of migrating these commands to the common views code structure will come in follow-up PRs, at which point we will be able to remove the UI instances from the unit tests for those commands.
2021-02-17 19:01:30 +01:00
if got, want := done(t).Stdout(), tc.want; got != want {
t.Errorf("wrong result\ngot: %q\nwant: %q", got, want)
}
})
}
}
func TestOperation_emergencyDumpState(t *testing.T) {
streams, done := terminal.StreamsForTesting(t)
v := NewOperation(arguments.ViewHuman, false, NewView(streams))
stateFile := statefile.New(nil, "foo", 1)
err := v.EmergencyDumpState(stateFile)
if err != nil {
t.Fatalf("unexpected error dumping state: %s", err)
}
// Check that the result (on stderr) looks like JSON state
raw := done(t).Stderr()
var state map[string]interface{}
if err := json.Unmarshal([]byte(raw), &state); err != nil {
t.Fatalf("unexpected error parsing dumped state: %s\nraw:\n%s", err, raw)
}
}
func TestOperation_planNoChanges(t *testing.T) {
command+backend/local: -refresh-only and drift detection This is a light revamp of our plan output to make use of Terraform core's new ability to report both the previous run state and the refreshed state, allowing us to explicitly report changes made outside of Terraform. Because whether a plan has "changes" or not is no longer such a straightforward matter, this now merges views.Operation.Plan with views.Operation.PlanNoChanges to produce a single function that knows how to report all of the various permutations. This was also an opportunity to fill some holes in our previous logic which caused it to produce some confusing messages, including a new tailored message for when "terraform destroy" detects that nothing needs to be destroyed. This also allows users to request the refresh-only planning mode using a new -refresh-only command line option. In that case, Terraform _only_ performs drift detection, and so applying a refresh-only plan only involves writing a new state snapshot, without changing any real infrastructure objects.
2021-05-07 00:22:48 +02:00
tests := map[string]struct {
plan func(schemas *terraform.Schemas) *plans.Plan
wantText string
}{
"nothing at all in normal mode": {
func(schemas *terraform.Schemas) *plans.Plan {
return &plans.Plan{
UIMode: plans.NormalMode,
Changes: plans.NewChanges(),
PrevRunState: states.NewState(),
PriorState: states.NewState(),
}
},
"no differences, so no changes are needed.",
},
"nothing at all in refresh-only mode": {
func(schemas *terraform.Schemas) *plans.Plan {
return &plans.Plan{
UIMode: plans.RefreshOnlyMode,
Changes: plans.NewChanges(),
PrevRunState: states.NewState(),
PriorState: states.NewState(),
}
},
"Terraform has checked that the real remote objects still match",
},
"nothing at all in destroy mode": {
func(schemas *terraform.Schemas) *plans.Plan {
return &plans.Plan{
UIMode: plans.DestroyMode,
Changes: plans.NewChanges(),
PrevRunState: states.NewState(),
PriorState: states.NewState(),
}
},
"No objects need to be destroyed.",
},
no drift with only deposed changes Changes to deposed instances should not triggers any drift to be rendered, as they will have nothing to display.
2021-05-24 23:02:15 +02:00
"no drift to display with only deposed instances": {
// changes in deposed instances will cause a change in state, but
// have nothing to display to the user
func(schemas *terraform.Schemas) *plans.Plan {
return &plans.Plan{
UIMode: plans.NormalMode,
Changes: plans.NewChanges(),
PrevRunState: states.BuildState(func(state *states.SyncState) {
state.SetResourceInstanceDeposed(
addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test_resource",
Name: "somewhere",
}.Instance(addrs.NoKey).Absolute(addrs.RootModuleInstance),
states.NewDeposedKey(),
&states.ResourceInstanceObjectSrc{
Status: states.ObjectReady,
AttrsJSON: []byte(`{"foo": "ok", "bars":[]}`),
},
addrs.RootModuleInstance.ProviderConfigDefault(addrs.NewDefaultProvider("test")),
)
}),
PriorState: states.NewState(),
}
},
"no differences, so no changes are needed.",
},
command+backend/local: -refresh-only and drift detection This is a light revamp of our plan output to make use of Terraform core's new ability to report both the previous run state and the refreshed state, allowing us to explicitly report changes made outside of Terraform. Because whether a plan has "changes" or not is no longer such a straightforward matter, this now merges views.Operation.Plan with views.Operation.PlanNoChanges to produce a single function that knows how to report all of the various permutations. This was also an opportunity to fill some holes in our previous logic which caused it to produce some confusing messages, including a new tailored message for when "terraform destroy" detects that nothing needs to be destroyed. This also allows users to request the refresh-only planning mode using a new -refresh-only command line option. In that case, Terraform _only_ performs drift detection, and so applying a refresh-only plan only involves writing a new state snapshot, without changing any real infrastructure objects.
2021-05-07 00:22:48 +02:00
"drift detected in normal mode": {
func(schemas *terraform.Schemas) *plans.Plan {
return &plans.Plan{
UIMode: plans.NormalMode,
Changes: plans.NewChanges(),
PrevRunState: states.BuildState(func(state *states.SyncState) {
state.SetResourceInstanceCurrent(
addrs.Resource{
Mode: addrs.ManagedResourceMode,
fix schemas and add deposed test The schemas for provider and the resources didn't match, so the changes were not going to be rendered at all. Add a test which contains a deposed resource.
2021-05-24 21:38:58 +02:00
Type: "test_resource",
command+backend/local: -refresh-only and drift detection This is a light revamp of our plan output to make use of Terraform core's new ability to report both the previous run state and the refreshed state, allowing us to explicitly report changes made outside of Terraform. Because whether a plan has "changes" or not is no longer such a straightforward matter, this now merges views.Operation.Plan with views.Operation.PlanNoChanges to produce a single function that knows how to report all of the various permutations. This was also an opportunity to fill some holes in our previous logic which caused it to produce some confusing messages, including a new tailored message for when "terraform destroy" detects that nothing needs to be destroyed. This also allows users to request the refresh-only planning mode using a new -refresh-only command line option. In that case, Terraform _only_ performs drift detection, and so applying a refresh-only plan only involves writing a new state snapshot, without changing any real infrastructure objects.
2021-05-07 00:22:48 +02:00
Name: "somewhere",
}.Instance(addrs.NoKey).Absolute(addrs.RootModuleInstance),
&states.ResourceInstanceObjectSrc{
Status: states.ObjectReady,
AttrsJSON: []byte(`{}`),
},
fix schemas and add deposed test The schemas for provider and the resources didn't match, so the changes were not going to be rendered at all. Add a test which contains a deposed resource.
2021-05-24 21:38:58 +02:00
addrs.RootModuleInstance.ProviderConfigDefault(addrs.NewDefaultProvider("test")),
command+backend/local: -refresh-only and drift detection This is a light revamp of our plan output to make use of Terraform core's new ability to report both the previous run state and the refreshed state, allowing us to explicitly report changes made outside of Terraform. Because whether a plan has "changes" or not is no longer such a straightforward matter, this now merges views.Operation.Plan with views.Operation.PlanNoChanges to produce a single function that knows how to report all of the various permutations. This was also an opportunity to fill some holes in our previous logic which caused it to produce some confusing messages, including a new tailored message for when "terraform destroy" detects that nothing needs to be destroyed. This also allows users to request the refresh-only planning mode using a new -refresh-only command line option. In that case, Terraform _only_ performs drift detection, and so applying a refresh-only plan only involves writing a new state snapshot, without changing any real infrastructure objects.
2021-05-07 00:22:48 +02:00
)
}),
PriorState: states.NewState(),
}
},
"to update the Terraform state to match, create and apply a refresh-only plan",
},
fix schemas and add deposed test The schemas for provider and the resources didn't match, so the changes were not going to be rendered at all. Add a test which contains a deposed resource.
2021-05-24 21:38:58 +02:00
"drift detected with deposed": {
func(schemas *terraform.Schemas) *plans.Plan {
return &plans.Plan{
UIMode: plans.NormalMode,
Changes: plans.NewChanges(),
PrevRunState: states.BuildState(func(state *states.SyncState) {
state.SetResourceInstanceCurrent(
addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test_resource",
Name: "changes",
}.Instance(addrs.NoKey).Absolute(addrs.RootModuleInstance),
&states.ResourceInstanceObjectSrc{
Status: states.ObjectReady,
AttrsJSON: []byte(`{"foo":"b"}`),
},
addrs.RootModuleInstance.ProviderConfigDefault(addrs.NewDefaultProvider("test")),
)
state.SetResourceInstanceDeposed(
addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test_resource",
Name: "broken",
}.Instance(addrs.NoKey).Absolute(addrs.RootModuleInstance),
states.NewDeposedKey(),
&states.ResourceInstanceObjectSrc{
Status: states.ObjectReady,
AttrsJSON: []byte(`{"foo":"c"}`),
},
addrs.RootModuleInstance.ProviderConfigDefault(addrs.NewDefaultProvider("test")),
)
}),
PriorState: states.BuildState(func(state *states.SyncState) {
state.SetResourceInstanceCurrent(
addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test_resource",
Name: "changed",
}.Instance(addrs.NoKey).Absolute(addrs.RootModuleInstance),
&states.ResourceInstanceObjectSrc{
Status: states.ObjectReady,
AttrsJSON: []byte(`{"foo":"b"}`),
},
addrs.RootModuleInstance.ProviderConfigDefault(addrs.NewDefaultProvider("test")),
)
state.SetResourceInstanceDeposed(
addrs.Resource{
Mode: addrs.ManagedResourceMode,
Type: "test_resource",
Name: "broken",
}.Instance(addrs.NoKey).Absolute(addrs.RootModuleInstance),
states.NewDeposedKey(),
&states.ResourceInstanceObjectSrc{
Status: states.ObjectReady,
AttrsJSON: []byte(`{"foo":"d"}`),
},
addrs.RootModuleInstance.ProviderConfigDefault(addrs.NewDefaultProvider("test")),
)
}),
}
},
"to update the Terraform state to match, create and apply a refresh-only plan",
},
command+backend/local: -refresh-only and drift detection This is a light revamp of our plan output to make use of Terraform core's new ability to report both the previous run state and the refreshed state, allowing us to explicitly report changes made outside of Terraform. Because whether a plan has "changes" or not is no longer such a straightforward matter, this now merges views.Operation.Plan with views.Operation.PlanNoChanges to produce a single function that knows how to report all of the various permutations. This was also an opportunity to fill some holes in our previous logic which caused it to produce some confusing messages, including a new tailored message for when "terraform destroy" detects that nothing needs to be destroyed. This also allows users to request the refresh-only planning mode using a new -refresh-only command line option. In that case, Terraform _only_ performs drift detection, and so applying a refresh-only plan only involves writing a new state snapshot, without changing any real infrastructure objects.
2021-05-07 00:22:48 +02:00
"drift detected in refresh-only mode": {
func(schemas *terraform.Schemas) *plans.Plan {
return &plans.Plan{
UIMode: plans.RefreshOnlyMode,
Changes: plans.NewChanges(),
PrevRunState: states.BuildState(func(state *states.SyncState) {
state.SetResourceInstanceCurrent(
addrs.Resource{
Mode: addrs.ManagedResourceMode,
fix schemas and add deposed test The schemas for provider and the resources didn't match, so the changes were not going to be rendered at all. Add a test which contains a deposed resource.
2021-05-24 21:38:58 +02:00
Type: "test_resource",
command+backend/local: -refresh-only and drift detection This is a light revamp of our plan output to make use of Terraform core's new ability to report both the previous run state and the refreshed state, allowing us to explicitly report changes made outside of Terraform. Because whether a plan has "changes" or not is no longer such a straightforward matter, this now merges views.Operation.Plan with views.Operation.PlanNoChanges to produce a single function that knows how to report all of the various permutations. This was also an opportunity to fill some holes in our previous logic which caused it to produce some confusing messages, including a new tailored message for when "terraform destroy" detects that nothing needs to be destroyed. This also allows users to request the refresh-only planning mode using a new -refresh-only command line option. In that case, Terraform _only_ performs drift detection, and so applying a refresh-only plan only involves writing a new state snapshot, without changing any real infrastructure objects.
2021-05-07 00:22:48 +02:00
Name: "somewhere",
}.Instance(addrs.NoKey).Absolute(addrs.RootModuleInstance),
&states.ResourceInstanceObjectSrc{
Status: states.ObjectReady,
AttrsJSON: []byte(`{}`),
},
fix schemas and add deposed test The schemas for provider and the resources didn't match, so the changes were not going to be rendered at all. Add a test which contains a deposed resource.
2021-05-24 21:38:58 +02:00
addrs.RootModuleInstance.ProviderConfigDefault(addrs.NewDefaultProvider("test")),
command+backend/local: -refresh-only and drift detection This is a light revamp of our plan output to make use of Terraform core's new ability to report both the previous run state and the refreshed state, allowing us to explicitly report changes made outside of Terraform. Because whether a plan has "changes" or not is no longer such a straightforward matter, this now merges views.Operation.Plan with views.Operation.PlanNoChanges to produce a single function that knows how to report all of the various permutations. This was also an opportunity to fill some holes in our previous logic which caused it to produce some confusing messages, including a new tailored message for when "terraform destroy" detects that nothing needs to be destroyed. This also allows users to request the refresh-only planning mode using a new -refresh-only command line option. In that case, Terraform _only_ performs drift detection, and so applying a refresh-only plan only involves writing a new state snapshot, without changing any real infrastructure objects.
2021-05-07 00:22:48 +02:00
)
}),
PriorState: states.NewState(),
}
},
"If you were expecting these changes then you can apply this plan",
},
"drift detected in destroy mode": {
func(schemas *terraform.Schemas) *plans.Plan {
return &plans.Plan{
UIMode: plans.DestroyMode,
Changes: plans.NewChanges(),
PrevRunState: states.BuildState(func(state *states.SyncState) {
state.SetResourceInstanceCurrent(
addrs.Resource{
Mode: addrs.ManagedResourceMode,
fix schemas and add deposed test The schemas for provider and the resources didn't match, so the changes were not going to be rendered at all. Add a test which contains a deposed resource.
2021-05-24 21:38:58 +02:00
Type: "test_resource",
command+backend/local: -refresh-only and drift detection This is a light revamp of our plan output to make use of Terraform core's new ability to report both the previous run state and the refreshed state, allowing us to explicitly report changes made outside of Terraform. Because whether a plan has "changes" or not is no longer such a straightforward matter, this now merges views.Operation.Plan with views.Operation.PlanNoChanges to produce a single function that knows how to report all of the various permutations. This was also an opportunity to fill some holes in our previous logic which caused it to produce some confusing messages, including a new tailored message for when "terraform destroy" detects that nothing needs to be destroyed. This also allows users to request the refresh-only planning mode using a new -refresh-only command line option. In that case, Terraform _only_ performs drift detection, and so applying a refresh-only plan only involves writing a new state snapshot, without changing any real infrastructure objects.
2021-05-07 00:22:48 +02:00
Name: "somewhere",
}.Instance(addrs.NoKey).Absolute(addrs.RootModuleInstance),
&states.ResourceInstanceObjectSrc{
Status: states.ObjectReady,
AttrsJSON: []byte(`{}`),
},
fix schemas and add deposed test The schemas for provider and the resources didn't match, so the changes were not going to be rendered at all. Add a test which contains a deposed resource.
2021-05-24 21:38:58 +02:00
addrs.RootModuleInstance.ProviderConfigDefault(addrs.NewDefaultProvider("test")),
command+backend/local: -refresh-only and drift detection This is a light revamp of our plan output to make use of Terraform core's new ability to report both the previous run state and the refreshed state, allowing us to explicitly report changes made outside of Terraform. Because whether a plan has "changes" or not is no longer such a straightforward matter, this now merges views.Operation.Plan with views.Operation.PlanNoChanges to produce a single function that knows how to report all of the various permutations. This was also an opportunity to fill some holes in our previous logic which caused it to produce some confusing messages, including a new tailored message for when "terraform destroy" detects that nothing needs to be destroyed. This also allows users to request the refresh-only planning mode using a new -refresh-only command line option. In that case, Terraform _only_ performs drift detection, and so applying a refresh-only plan only involves writing a new state snapshot, without changing any real infrastructure objects.
2021-05-07 00:22:48 +02:00
)
}),
PriorState: states.NewState(),
}
},
"No objects need to be destroyed.",
},
}
backend/local: Replace CLI with view instance This commit extracts the remaining UI logic from the local backend, and removes access to the direct CLI output. This is replaced with an instance of a `views.Operation` interface, which codifies the current requirements for the local backend to interact with the user. The exception to this at present is interactivity: approving a plan still depends on the `UIIn` field for the backend. This is out of scope for this commit and can be revisited separately, at which time the `UIOut` field can also be removed. Changes in support of this: - Some instances of direct error output have been replaced with diagnostics, most notably in the emergency state backup handler. This requires reformatting the error messages to allow the diagnostic renderer to line-wrap them; - The "in-automation" logic has moved out of the backend and into the view implementation; - The plan, apply, refresh, and import commands instantiate a view and set it on the `backend.Operation` struct, as these are the only code paths which call the `local.Operation()` method that requires it; - The show command requires the plan rendering code which is now in the views package, so there is a stub implementation of a `views.Show` interface there. Other refactoring work in support of migrating these commands to the common views code structure will come in follow-up PRs, at which point we will be able to remove the UI instances from the unit tests for those commands.
2021-02-17 19:01:30 +01:00
command+backend/local: -refresh-only and drift detection This is a light revamp of our plan output to make use of Terraform core's new ability to report both the previous run state and the refreshed state, allowing us to explicitly report changes made outside of Terraform. Because whether a plan has "changes" or not is no longer such a straightforward matter, this now merges views.Operation.Plan with views.Operation.PlanNoChanges to produce a single function that knows how to report all of the various permutations. This was also an opportunity to fill some holes in our previous logic which caused it to produce some confusing messages, including a new tailored message for when "terraform destroy" detects that nothing needs to be destroyed. This also allows users to request the refresh-only planning mode using a new -refresh-only command line option. In that case, Terraform _only_ performs drift detection, and so applying a refresh-only plan only involves writing a new state snapshot, without changing any real infrastructure objects.
2021-05-07 00:22:48 +02:00
schemas := testSchemas()
for name, test := range tests {
t.Run(name, func(t *testing.T) {
streams, done := terminal.StreamsForTesting(t)
v := NewOperation(arguments.ViewHuman, false, NewView(streams))
plan := test.plan(schemas)
v.Plan(plan, schemas)
got := done(t).Stdout()
if want := test.wantText; want != "" && !strings.Contains(got, want) {
t.Errorf("missing expected message\ngot:\n%s\n\nwant substring: %s", got, want)
}
})
backend/local: Replace CLI with view instance This commit extracts the remaining UI logic from the local backend, and removes access to the direct CLI output. This is replaced with an instance of a `views.Operation` interface, which codifies the current requirements for the local backend to interact with the user. The exception to this at present is interactivity: approving a plan still depends on the `UIIn` field for the backend. This is out of scope for this commit and can be revisited separately, at which time the `UIOut` field can also be removed. Changes in support of this: - Some instances of direct error output have been replaced with diagnostics, most notably in the emergency state backup handler. This requires reformatting the error messages to allow the diagnostic renderer to line-wrap them; - The "in-automation" logic has moved out of the backend and into the view implementation; - The plan, apply, refresh, and import commands instantiate a view and set it on the `backend.Operation` struct, as these are the only code paths which call the `local.Operation()` method that requires it; - The show command requires the plan rendering code which is now in the views package, so there is a stub implementation of a `views.Show` interface there. Other refactoring work in support of migrating these commands to the common views code structure will come in follow-up PRs, at which point we will be able to remove the UI instances from the unit tests for those commands.
2021-02-17 19:01:30 +01:00
}
}
func TestOperation_plan(t *testing.T) {
streams, done := terminal.StreamsForTesting(t)
v := NewOperation(arguments.ViewHuman, true, NewView(streams))
plan := testPlan(t)
schemas := testSchemas()
command/views: Remove baseState argument from plan-rendering views In practice the current implementation isn't actually using this, and if we need access to states in future we can access them in either the plan.PriorState or plan.PrevRunState fields, depending on which stage we want a state snapshot of.
2021-05-06 00:24:58 +02:00
v.Plan(plan, schemas)
backend/local: Replace CLI with view instance This commit extracts the remaining UI logic from the local backend, and removes access to the direct CLI output. This is replaced with an instance of a `views.Operation` interface, which codifies the current requirements for the local backend to interact with the user. The exception to this at present is interactivity: approving a plan still depends on the `UIIn` field for the backend. This is out of scope for this commit and can be revisited separately, at which time the `UIOut` field can also be removed. Changes in support of this: - Some instances of direct error output have been replaced with diagnostics, most notably in the emergency state backup handler. This requires reformatting the error messages to allow the diagnostic renderer to line-wrap them; - The "in-automation" logic has moved out of the backend and into the view implementation; - The plan, apply, refresh, and import commands instantiate a view and set it on the `backend.Operation` struct, as these are the only code paths which call the `local.Operation()` method that requires it; - The show command requires the plan rendering code which is now in the views package, so there is a stub implementation of a `views.Show` interface there. Other refactoring work in support of migrating these commands to the common views code structure will come in follow-up PRs, at which point we will be able to remove the UI instances from the unit tests for those commands.
2021-02-17 19:01:30 +01:00
want := `
Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
+ create
Terraform will perform the following actions:
# test_resource.foo will be created
+ resource "test_resource" "foo" {
+ foo = "bar"
+ id = (known after apply)
}
Plan: 1 to add, 0 to change, 0 to destroy.
`
if got := done(t).Stdout(); got != want {
t.Errorf("unexpected output\ngot:\n%s\nwant:\n%s", got, want)
}
}
func TestOperation_planNextStep(t *testing.T) {
testCases := map[string]struct {
path string
want string
}{
"no state path": {
path: "",
want: "You didn't use the -out option",
},
"state path": {
path: "good plan.tfplan",
want: `terraform apply "good plan.tfplan"`,
},
}
for name, tc := range testCases {
t.Run(name, func(t *testing.T) {
streams, done := terminal.StreamsForTesting(t)
v := NewOperation(arguments.ViewHuman, false, NewView(streams))
v.PlanNextStep(tc.path)
if got := done(t).Stdout(); !strings.Contains(got, tc.want) {
t.Errorf("wrong result\ngot: %q\nwant: %q", got, tc.want)
}
})
}
}
// The in-automation state is on the view itself, so testing it separately is
// clearer.
func TestOperation_planNextStepInAutomation(t *testing.T) {
streams, done := terminal.StreamsForTesting(t)
v := NewOperation(arguments.ViewHuman, true, NewView(streams))
v.PlanNextStep("")
if got := done(t).Stdout(); got != "" {
t.Errorf("unexpected output\ngot: %q", got)
}
}
cli: Add JSON logs for operations commands
2021-02-23 16:16:09 +01:00
// Test all the trivial OperationJSON methods together. Y'know, for brevity.
// This test is not a realistic stream of messages.
func TestOperationJSON_logs(t *testing.T) {
streams, done := terminal.StreamsForTesting(t)
v := &OperationJSON{view: NewJSONView(NewView(streams))}
v.Cancelled(plans.NormalMode)
v.Cancelled(plans.DestroyMode)
v.Stopping()
v.Interrupted()
v.FatalInterrupt()
want := []map[string]interface{}{
{
"@level": "info",
"@message": "Apply cancelled",
"@module": "terraform.ui",
"type": "log",
},
{
"@level": "info",
"@message": "Destroy cancelled",
"@module": "terraform.ui",
"type": "log",
},
{
"@level": "info",
"@message": "Stopping operation...",
"@module": "terraform.ui",
"type": "log",
},
{
"@level": "info",
"@message": interrupted,
"@module": "terraform.ui",
"type": "log",
},
{
"@level": "info",
"@message": fatalInterrupt,
"@module": "terraform.ui",
"type": "log",
},
}
testJSONViewOutputEquals(t, done(t).Stdout(), want)
}
// This is a fairly circular test, but it's such a rarely executed code path
// that I think it's probably still worth having. We're not testing against
// a fixed state JSON output because this test ought not fail just because
// we upgrade state format in the future.
func TestOperationJSON_emergencyDumpState(t *testing.T) {
streams, done := terminal.StreamsForTesting(t)
v := &OperationJSON{view: NewJSONView(NewView(streams))}
stateFile := statefile.New(nil, "foo", 1)
stateBuf := new(bytes.Buffer)
err := statefile.Write(stateFile, stateBuf)
if err != nil {
t.Fatal(err)
}
var stateJSON map[string]interface{}
err = json.Unmarshal(stateBuf.Bytes(), &stateJSON)
if err != nil {
t.Fatal(err)
}
err = v.EmergencyDumpState(stateFile)
if err != nil {
t.Fatalf("unexpected error dumping state: %s", err)
}
want := []map[string]interface{}{
{
"@level": "info",
"@message": "Emergency state dump",
"@module": "terraform.ui",
"type": "log",
"state": stateJSON,
},
}
testJSONViewOutputEquals(t, done(t).Stdout(), want)
}
func TestOperationJSON_planNoChanges(t *testing.T) {
streams, done := terminal.StreamsForTesting(t)
v := &OperationJSON{view: NewJSONView(NewView(streams))}
command+backend/local: -refresh-only and drift detection This is a light revamp of our plan output to make use of Terraform core's new ability to report both the previous run state and the refreshed state, allowing us to explicitly report changes made outside of Terraform. Because whether a plan has "changes" or not is no longer such a straightforward matter, this now merges views.Operation.Plan with views.Operation.PlanNoChanges to produce a single function that knows how to report all of the various permutations. This was also an opportunity to fill some holes in our previous logic which caused it to produce some confusing messages, including a new tailored message for when "terraform destroy" detects that nothing needs to be destroyed. This also allows users to request the refresh-only planning mode using a new -refresh-only command line option. In that case, Terraform _only_ performs drift detection, and so applying a refresh-only plan only involves writing a new state snapshot, without changing any real infrastructure objects.
2021-05-07 00:22:48 +02:00
plan := &plans.Plan{
Changes: plans.NewChanges(),
}
v.Plan(plan, nil)
cli: Add JSON logs for operations commands
2021-02-23 16:16:09 +01:00
want := []map[string]interface{}{
{
"@level": "info",
"@message": "Plan: 0 to add, 0 to change, 0 to destroy.",
"@module": "terraform.ui",
"type": "change_summary",
"changes": map[string]interface{}{
"operation": "plan",
"add": float64(0),
"change": float64(0),
"remove": float64(0),
},
},
}
testJSONViewOutputEquals(t, done(t).Stdout(), want)
}
func TestOperationJSON_plan(t *testing.T) {
streams, done := terminal.StreamsForTesting(t)
v := &OperationJSON{view: NewJSONView(NewView(streams))}
root := addrs.RootModuleInstance
vpc, diags := addrs.ParseModuleInstanceStr("module.vpc")
if len(diags) > 0 {
t.Fatal(diags.Err())
}
json-output: Add resource drift to machine readable UI
2021-06-29 20:14:31 +02:00
boop := addrs.Resource{Mode: addrs.ManagedResourceMode, Type: "test_resource", Name: "boop"}
beep := addrs.Resource{Mode: addrs.ManagedResourceMode, Type: "test_resource", Name: "beep"}
cli: Add JSON logs for operations commands
2021-02-23 16:16:09 +01:00
derp := addrs.Resource{Mode: addrs.DataResourceMode, Type: "test_source", Name: "derp"}
plan := &plans.Plan{
Changes: &plans.Changes{
Resources: []*plans.ResourceInstanceChangeSrc{
{
Addr: boop.Instance(addrs.IntKey(0)).Absolute(root),
ChangeSrc: plans.ChangeSrc{Action: plans.CreateThenDelete},
},
{
Addr: boop.Instance(addrs.IntKey(1)).Absolute(root),
ChangeSrc: plans.ChangeSrc{Action: plans.Create},
},
{
Addr: boop.Instance(addrs.IntKey(0)).Absolute(vpc),
ChangeSrc: plans.ChangeSrc{Action: plans.Delete},
},
{
Addr: beep.Instance(addrs.NoKey).Absolute(root),
ChangeSrc: plans.ChangeSrc{Action: plans.DeleteThenCreate},
},
{
Addr: beep.Instance(addrs.NoKey).Absolute(vpc),
ChangeSrc: plans.ChangeSrc{Action: plans.Update},
},
// Data source deletion should not show up in the logs
{
Addr: derp.Instance(addrs.NoKey).Absolute(root),
ChangeSrc: plans.ChangeSrc{Action: plans.Delete},
},
},
},
}
json-output: Add resource drift to machine readable UI
2021-06-29 20:14:31 +02:00
v.Plan(plan, testSchemas())
cli: Add JSON logs for operations commands
2021-02-23 16:16:09 +01:00
want := []map[string]interface{}{
// Create-then-delete should result in replace
{
"@level": "info",
json-output: Add resource drift to machine readable UI
2021-06-29 20:14:31 +02:00
"@message": "test_resource.boop[0]: Plan to replace",
cli: Add JSON logs for operations commands
2021-02-23 16:16:09 +01:00
"@module": "terraform.ui",
"type": "planned_change",
"change": map[string]interface{}{
"action": "replace",
"resource": map[string]interface{}{
json-output: Add resource drift to machine readable UI
2021-06-29 20:14:31 +02:00
"addr": `test_resource.boop[0]`,
cli: Add JSON logs for operations commands
2021-02-23 16:16:09 +01:00
"implied_provider": "test",
"module": "",
json-output: Add resource drift to machine readable UI
2021-06-29 20:14:31 +02:00
"resource": `test_resource.boop[0]`,
cli: Add JSON logs for operations commands
2021-02-23 16:16:09 +01:00
"resource_key": float64(0),
"resource_name": "boop",
json-output: Add resource drift to machine readable UI
2021-06-29 20:14:31 +02:00
"resource_type": "test_resource",
cli: Add JSON logs for operations commands
2021-02-23 16:16:09 +01:00
},
},
},
// Simple create
{
"@level": "info",
json-output: Add resource drift to machine readable UI
2021-06-29 20:14:31 +02:00
"@message": "test_resource.boop[1]: Plan to create",
cli: Add JSON logs for operations commands
2021-02-23 16:16:09 +01:00
"@module": "terraform.ui",
"type": "planned_change",
"change": map[string]interface{}{
"action": "create",
"resource": map[string]interface{}{
json-output: Add resource drift to machine readable UI
2021-06-29 20:14:31 +02:00
"addr": `test_resource.boop[1]`,
cli: Add JSON logs for operations commands
2021-02-23 16:16:09 +01:00
"implied_provider": "test",
"module": "",
json-output: Add resource drift to machine readable UI
2021-06-29 20:14:31 +02:00
"resource": `test_resource.boop[1]`,
cli: Add JSON logs for operations commands
2021-02-23 16:16:09 +01:00
"resource_key": float64(1),
"resource_name": "boop",
json-output: Add resource drift to machine readable UI
2021-06-29 20:14:31 +02:00
"resource_type": "test_resource",
cli: Add JSON logs for operations commands
2021-02-23 16:16:09 +01:00
},
},
},
// Simple delete
{
"@level": "info",
json-output: Add resource drift to machine readable UI
2021-06-29 20:14:31 +02:00
"@message": "module.vpc.test_resource.boop[0]: Plan to delete",
cli: Add JSON logs for operations commands
2021-02-23 16:16:09 +01:00
"@module": "terraform.ui",
"type": "planned_change",
"change": map[string]interface{}{
"action": "delete",
"resource": map[string]interface{}{
json-output: Add resource drift to machine readable UI
2021-06-29 20:14:31 +02:00
"addr": `module.vpc.test_resource.boop[0]`,
cli: Add JSON logs for operations commands
2021-02-23 16:16:09 +01:00
"implied_provider": "test",
"module": "module.vpc",
json-output: Add resource drift to machine readable UI
2021-06-29 20:14:31 +02:00
"resource": `test_resource.boop[0]`,
cli: Add JSON logs for operations commands
2021-02-23 16:16:09 +01:00
"resource_key": float64(0),
"resource_name": "boop",
json-output: Add resource drift to machine readable UI
2021-06-29 20:14:31 +02:00
"resource_type": "test_resource",
cli: Add JSON logs for operations commands
2021-02-23 16:16:09 +01:00
},
},
},
// Delete-then-create is also a replace
{
"@level": "info",
json-output: Add resource drift to machine readable UI
2021-06-29 20:14:31 +02:00
"@message": "test_resource.beep: Plan to replace",
cli: Add JSON logs for operations commands
2021-02-23 16:16:09 +01:00
"@module": "terraform.ui",
"type": "planned_change",
"change": map[string]interface{}{
"action": "replace",
"resource": map[string]interface{}{
json-output: Add resource drift to machine readable UI
2021-06-29 20:14:31 +02:00
"addr": `test_resource.beep`,
cli: Add JSON logs for operations commands
2021-02-23 16:16:09 +01:00
"implied_provider": "test",
"module": "",
json-output: Add resource drift to machine readable UI
2021-06-29 20:14:31 +02:00
"resource": `test_resource.beep`,
cli: Add JSON logs for operations commands
2021-02-23 16:16:09 +01:00
"resource_key": nil,
"resource_name": "beep",
json-output: Add resource drift to machine readable UI
2021-06-29 20:14:31 +02:00
"resource_type": "test_resource",
cli: Add JSON logs for operations commands
2021-02-23 16:16:09 +01:00
},
},
},
// Simple update
{
"@level": "info",
json-output: Add resource drift to machine readable UI
2021-06-29 20:14:31 +02:00
"@message": "module.vpc.test_resource.beep: Plan to update",
cli: Add JSON logs for operations commands
2021-02-23 16:16:09 +01:00
"@module": "terraform.ui",
"type": "planned_change",
"change": map[string]interface{}{
"action": "update",
"resource": map[string]interface{}{
json-output: Add resource drift to machine readable UI
2021-06-29 20:14:31 +02:00
"addr": `module.vpc.test_resource.beep`,
cli: Add JSON logs for operations commands
2021-02-23 16:16:09 +01:00
"implied_provider": "test",
"module": "module.vpc",
json-output: Add resource drift to machine readable UI
2021-06-29 20:14:31 +02:00
"resource": `test_resource.beep`,
cli: Add JSON logs for operations commands
2021-02-23 16:16:09 +01:00
"resource_key": nil,
"resource_name": "beep",
json-output: Add resource drift to machine readable UI
2021-06-29 20:14:31 +02:00
"resource_type": "test_resource",
cli: Add JSON logs for operations commands
2021-02-23 16:16:09 +01:00
},
},
},
// These counts are 3 add/1 change/3 destroy because the replace
// changes result in both add and destroy counts.
{
"@level": "info",
"@message": "Plan: 3 to add, 1 to change, 3 to destroy.",
"@module": "terraform.ui",
"type": "change_summary",
"changes": map[string]interface{}{
"operation": "plan",
"add": float64(3),
"change": float64(1),
"remove": float64(3),
},
},
}
testJSONViewOutputEquals(t, done(t).Stdout(), want)
}
Fix flapping JSON output test This test would previously fail randomly due to the use of multiple resource instances. Instance keys are iterated over as a map for presentation, which has intentionally inconsistent ordering. To fix this, I changed the test to use different resource addresses for the three drift cases. I also extracted them to a separate test, and tweaked the test helper functions to reduce the number of fatal exit points, to make failed test debugging easier.
2021-07-15 18:03:01 +02:00
func TestOperationJSON_planDrift(t *testing.T) {
streams, done := terminal.StreamsForTesting(t)
v := &OperationJSON{view: NewJSONView(NewView(streams))}
root := addrs.RootModuleInstance
boop := addrs.Resource{Mode: addrs.ManagedResourceMode, Type: "test_resource", Name: "boop"}
beep := addrs.Resource{Mode: addrs.ManagedResourceMode, Type: "test_resource", Name: "beep"}
derp := addrs.Resource{Mode: addrs.ManagedResourceMode, Type: "test_resource", Name: "derp"}
plan := &plans.Plan{
Changes: &plans.Changes{
Resources: []*plans.ResourceInstanceChangeSrc{},
},
PrevRunState: states.BuildState(func(state *states.SyncState) {
// Update
state.SetResourceInstanceCurrent(
boop.Instance(addrs.NoKey).Absolute(root),
&states.ResourceInstanceObjectSrc{
Status: states.ObjectReady,
AttrsJSON: []byte(`{"foo":"bar"}`),
},
root.ProviderConfigDefault(addrs.NewDefaultProvider("test")),
)
// Delete
state.SetResourceInstanceCurrent(
beep.Instance(addrs.NoKey).Absolute(root),
&states.ResourceInstanceObjectSrc{
Status: states.ObjectReady,
AttrsJSON: []byte(`{"foo":"boop"}`),
},
root.ProviderConfigDefault(addrs.NewDefaultProvider("test")),
)
// No-op
state.SetResourceInstanceCurrent(
derp.Instance(addrs.NoKey).Absolute(root),
&states.ResourceInstanceObjectSrc{
Status: states.ObjectReady,
AttrsJSON: []byte(`{"foo":"boop"}`),
},
root.ProviderConfigDefault(addrs.NewDefaultProvider("test")),
)
}),
PriorState: states.BuildState(func(state *states.SyncState) {
// Update
state.SetResourceInstanceCurrent(
boop.Instance(addrs.NoKey).Absolute(root),
&states.ResourceInstanceObjectSrc{
Status: states.ObjectReady,
AttrsJSON: []byte(`{"foo":"baz"}`),
},
root.ProviderConfigDefault(addrs.NewDefaultProvider("test")),
)
// Delete
state.SetResourceInstanceCurrent(
beep.Instance(addrs.NoKey).Absolute(root),
nil,
root.ProviderConfigDefault(addrs.NewDefaultProvider("test")),
)
// No-op
state.SetResourceInstanceCurrent(
derp.Instance(addrs.NoKey).Absolute(root),
&states.ResourceInstanceObjectSrc{
Status: states.ObjectReady,
AttrsJSON: []byte(`{"foo":"boop"}`),
},
root.ProviderConfigDefault(addrs.NewDefaultProvider("test")),
)
}),
}
v.Plan(plan, testSchemas())
want := []map[string]interface{}{
Fix flapping JSON output test properly This commit makes the output order of the resource drift messages stable, by building a slice of changes and sorting it by address.
2021-07-15 19:30:11 +02:00
// Drift detected: delete
Fix flapping JSON output test This test would previously fail randomly due to the use of multiple resource instances. Instance keys are iterated over as a map for presentation, which has intentionally inconsistent ordering. To fix this, I changed the test to use different resource addresses for the three drift cases. I also extracted them to a separate test, and tweaked the test helper functions to reduce the number of fatal exit points, to make failed test debugging easier.
2021-07-15 18:03:01 +02:00
{
"@level": "info",
Fix flapping JSON output test properly This commit makes the output order of the resource drift messages stable, by building a slice of changes and sorting it by address.
2021-07-15 19:30:11 +02:00
"@message": "test_resource.beep: Drift detected (delete)",
Fix flapping JSON output test This test would previously fail randomly due to the use of multiple resource instances. Instance keys are iterated over as a map for presentation, which has intentionally inconsistent ordering. To fix this, I changed the test to use different resource addresses for the three drift cases. I also extracted them to a separate test, and tweaked the test helper functions to reduce the number of fatal exit points, to make failed test debugging easier.
2021-07-15 18:03:01 +02:00
"@module": "terraform.ui",
"type": "resource_drift",
"change": map[string]interface{}{
Fix flapping JSON output test properly This commit makes the output order of the resource drift messages stable, by building a slice of changes and sorting it by address.
2021-07-15 19:30:11 +02:00
"action": "delete",
Fix flapping JSON output test This test would previously fail randomly due to the use of multiple resource instances. Instance keys are iterated over as a map for presentation, which has intentionally inconsistent ordering. To fix this, I changed the test to use different resource addresses for the three drift cases. I also extracted them to a separate test, and tweaked the test helper functions to reduce the number of fatal exit points, to make failed test debugging easier.
2021-07-15 18:03:01 +02:00
"resource": map[string]interface{}{
Fix flapping JSON output test properly This commit makes the output order of the resource drift messages stable, by building a slice of changes and sorting it by address.
2021-07-15 19:30:11 +02:00
"addr": "test_resource.beep",
Fix flapping JSON output test This test would previously fail randomly due to the use of multiple resource instances. Instance keys are iterated over as a map for presentation, which has intentionally inconsistent ordering. To fix this, I changed the test to use different resource addresses for the three drift cases. I also extracted them to a separate test, and tweaked the test helper functions to reduce the number of fatal exit points, to make failed test debugging easier.
2021-07-15 18:03:01 +02:00
"implied_provider": "test",
"module": "",
Fix flapping JSON output test properly This commit makes the output order of the resource drift messages stable, by building a slice of changes and sorting it by address.
2021-07-15 19:30:11 +02:00
"resource": "test_resource.beep",
Fix flapping JSON output test This test would previously fail randomly due to the use of multiple resource instances. Instance keys are iterated over as a map for presentation, which has intentionally inconsistent ordering. To fix this, I changed the test to use different resource addresses for the three drift cases. I also extracted them to a separate test, and tweaked the test helper functions to reduce the number of fatal exit points, to make failed test debugging easier.
2021-07-15 18:03:01 +02:00
"resource_key": nil,
Fix flapping JSON output test properly This commit makes the output order of the resource drift messages stable, by building a slice of changes and sorting it by address.
2021-07-15 19:30:11 +02:00
"resource_name": "beep",
Fix flapping JSON output test This test would previously fail randomly due to the use of multiple resource instances. Instance keys are iterated over as a map for presentation, which has intentionally inconsistent ordering. To fix this, I changed the test to use different resource addresses for the three drift cases. I also extracted them to a separate test, and tweaked the test helper functions to reduce the number of fatal exit points, to make failed test debugging easier.
2021-07-15 18:03:01 +02:00
"resource_type": "test_resource",
},
},
},
Fix flapping JSON output test properly This commit makes the output order of the resource drift messages stable, by building a slice of changes and sorting it by address.
2021-07-15 19:30:11 +02:00
// Drift detected: update
Fix flapping JSON output test This test would previously fail randomly due to the use of multiple resource instances. Instance keys are iterated over as a map for presentation, which has intentionally inconsistent ordering. To fix this, I changed the test to use different resource addresses for the three drift cases. I also extracted them to a separate test, and tweaked the test helper functions to reduce the number of fatal exit points, to make failed test debugging easier.
2021-07-15 18:03:01 +02:00
{
"@level": "info",
Fix flapping JSON output test properly This commit makes the output order of the resource drift messages stable, by building a slice of changes and sorting it by address.
2021-07-15 19:30:11 +02:00
"@message": "test_resource.boop: Drift detected (update)",
Fix flapping JSON output test This test would previously fail randomly due to the use of multiple resource instances. Instance keys are iterated over as a map for presentation, which has intentionally inconsistent ordering. To fix this, I changed the test to use different resource addresses for the three drift cases. I also extracted them to a separate test, and tweaked the test helper functions to reduce the number of fatal exit points, to make failed test debugging easier.
2021-07-15 18:03:01 +02:00
"@module": "terraform.ui",
"type": "resource_drift",
"change": map[string]interface{}{
Fix flapping JSON output test properly This commit makes the output order of the resource drift messages stable, by building a slice of changes and sorting it by address.
2021-07-15 19:30:11 +02:00
"action": "update",
Fix flapping JSON output test This test would previously fail randomly due to the use of multiple resource instances. Instance keys are iterated over as a map for presentation, which has intentionally inconsistent ordering. To fix this, I changed the test to use different resource addresses for the three drift cases. I also extracted them to a separate test, and tweaked the test helper functions to reduce the number of fatal exit points, to make failed test debugging easier.
2021-07-15 18:03:01 +02:00
"resource": map[string]interface{}{
Fix flapping JSON output test properly This commit makes the output order of the resource drift messages stable, by building a slice of changes and sorting it by address.
2021-07-15 19:30:11 +02:00
"addr": "test_resource.boop",
Fix flapping JSON output test This test would previously fail randomly due to the use of multiple resource instances. Instance keys are iterated over as a map for presentation, which has intentionally inconsistent ordering. To fix this, I changed the test to use different resource addresses for the three drift cases. I also extracted them to a separate test, and tweaked the test helper functions to reduce the number of fatal exit points, to make failed test debugging easier.
2021-07-15 18:03:01 +02:00
"implied_provider": "test",
"module": "",
Fix flapping JSON output test properly This commit makes the output order of the resource drift messages stable, by building a slice of changes and sorting it by address.
2021-07-15 19:30:11 +02:00
"resource": "test_resource.boop",
Fix flapping JSON output test This test would previously fail randomly due to the use of multiple resource instances. Instance keys are iterated over as a map for presentation, which has intentionally inconsistent ordering. To fix this, I changed the test to use different resource addresses for the three drift cases. I also extracted them to a separate test, and tweaked the test helper functions to reduce the number of fatal exit points, to make failed test debugging easier.
2021-07-15 18:03:01 +02:00
"resource_key": nil,
Fix flapping JSON output test properly This commit makes the output order of the resource drift messages stable, by building a slice of changes and sorting it by address.
2021-07-15 19:30:11 +02:00
"resource_name": "boop",
Fix flapping JSON output test This test would previously fail randomly due to the use of multiple resource instances. Instance keys are iterated over as a map for presentation, which has intentionally inconsistent ordering. To fix this, I changed the test to use different resource addresses for the three drift cases. I also extracted them to a separate test, and tweaked the test helper functions to reduce the number of fatal exit points, to make failed test debugging easier.
2021-07-15 18:03:01 +02:00
"resource_type": "test_resource",
},
},
},
// No changes
{
"@level": "info",
"@message": "Plan: 0 to add, 0 to change, 0 to destroy.",
"@module": "terraform.ui",
"type": "change_summary",
"changes": map[string]interface{}{
"operation": "plan",
"add": float64(0),
"change": float64(0),
"remove": float64(0),
},
},
}
testJSONViewOutputEquals(t, done(t).Stdout(), want)
}
json-output: Add output changes to plan logs Extend the outputs JSON log message to support an `action` field (and make the `type` and `value` fields optional). This allows us to emit a useful output change summary as part of the plan, bringing the JSON log output into parity with the text output. While we do have access to the before/after values in the output changes, attempting to wedge those into a structured log message is not appropriate. That level of detail can be extracted from the JSON plan output from `terraform show -json`.
2021-07-30 19:37:23 +02:00
func TestOperationJSON_planOutputChanges(t *testing.T) {
streams, done := terminal.StreamsForTesting(t)
v := &OperationJSON{view: NewJSONView(NewView(streams))}
root := addrs.RootModuleInstance
plan := &plans.Plan{
Changes: &plans.Changes{
Resources: []*plans.ResourceInstanceChangeSrc{},
Outputs: []*plans.OutputChangeSrc{
{
Addr: root.OutputValue("boop"),
ChangeSrc: plans.ChangeSrc{
Action: plans.NoOp,
},
},
{
Addr: root.OutputValue("beep"),
ChangeSrc: plans.ChangeSrc{
Action: plans.Create,
},
},
{
Addr: root.OutputValue("bonk"),
ChangeSrc: plans.ChangeSrc{
Action: plans.Delete,
},
},
{
Addr: root.OutputValue("honk"),
ChangeSrc: plans.ChangeSrc{
Action: plans.Update,
},
Sensitive: true,
},
},
},
}
v.Plan(plan, testSchemas())
want := []map[string]interface{}{
// No resource changes
{
"@level": "info",
"@message": "Plan: 0 to add, 0 to change, 0 to destroy.",
"@module": "terraform.ui",
"type": "change_summary",
"changes": map[string]interface{}{
"operation": "plan",
"add": float64(0),
"change": float64(0),
"remove": float64(0),
},
},
// Output changes
{
"@level": "info",
"@message": "Outputs: 4",
"@module": "terraform.ui",
"type": "outputs",
"outputs": map[string]interface{}{
"boop": map[string]interface{}{
"action": "noop",
"sensitive": false,
},
"beep": map[string]interface{}{
"action": "create",
"sensitive": false,
},
"bonk": map[string]interface{}{
"action": "delete",
"sensitive": false,
},
"honk": map[string]interface{}{
"action": "update",
"sensitive": true,
},
},
},
}
testJSONViewOutputEquals(t, done(t).Stdout(), want)
}
cli: Add JSON logs for operations commands
2021-02-23 16:16:09 +01:00
func TestOperationJSON_plannedChange(t *testing.T) {
streams, done := terminal.StreamsForTesting(t)
v := &OperationJSON{view: NewJSONView(NewView(streams))}
root := addrs.RootModuleInstance
boop := addrs.Resource{Mode: addrs.ManagedResourceMode, Type: "test_instance", Name: "boop"}
derp := addrs.Resource{Mode: addrs.DataResourceMode, Type: "test_source", Name: "derp"}
command/views: Add reason to JSON planned change Now that we have extra information about the reason for a given resource action, include that in the JSON log output for planned changes.
2021-05-03 12:49:42 +02:00
// Replace requested by user
v.PlannedChange(&plans.ResourceInstanceChangeSrc{
Addr: boop.Instance(addrs.IntKey(0)).Absolute(root),
ChangeSrc: plans.ChangeSrc{Action: plans.DeleteThenCreate},
ActionReason: plans.ResourceInstanceReplaceByRequest,
})
cli: Add JSON logs for operations commands
2021-02-23 16:16:09 +01:00
// Simple create
v.PlannedChange(&plans.ResourceInstanceChangeSrc{
command/views: Add reason to JSON planned change Now that we have extra information about the reason for a given resource action, include that in the JSON log output for planned changes.
2021-05-03 12:49:42 +02:00
Addr: boop.Instance(addrs.IntKey(1)).Absolute(root),
cli: Add JSON logs for operations commands
2021-02-23 16:16:09 +01:00
ChangeSrc: plans.ChangeSrc{Action: plans.Create},
})
// Data source deletion
v.PlannedChange(&plans.ResourceInstanceChangeSrc{
Addr: derp.Instance(addrs.NoKey).Absolute(root),
ChangeSrc: plans.ChangeSrc{Action: plans.Delete},
})
command/views: Add reason to JSON planned change Now that we have extra information about the reason for a given resource action, include that in the JSON log output for planned changes.
2021-05-03 12:49:42 +02:00
// Expect only two messages, as the data source deletion should be a no-op
cli: Add JSON logs for operations commands
2021-02-23 16:16:09 +01:00
want := []map[string]interface{}{
{
"@level": "info",
command/views: Add reason to JSON planned change Now that we have extra information about the reason for a given resource action, include that in the JSON log output for planned changes.
2021-05-03 12:49:42 +02:00
"@message": "test_instance.boop[0]: Plan to replace",
cli: Add JSON logs for operations commands
2021-02-23 16:16:09 +01:00
"@module": "terraform.ui",
"type": "planned_change",
"change": map[string]interface{}{
command/views: Add reason to JSON planned change Now that we have extra information about the reason for a given resource action, include that in the JSON log output for planned changes.
2021-05-03 12:49:42 +02:00
"action": "replace",
"reason": "requested",
cli: Add JSON logs for operations commands
2021-02-23 16:16:09 +01:00
"resource": map[string]interface{}{
"addr": `test_instance.boop[0]`,
"implied_provider": "test",
"module": "",
"resource": `test_instance.boop[0]`,
"resource_key": float64(0),
"resource_name": "boop",
"resource_type": "test_instance",
},
},
},
command/views: Add reason to JSON planned change Now that we have extra information about the reason for a given resource action, include that in the JSON log output for planned changes.
2021-05-03 12:49:42 +02:00
{
"@level": "info",
"@message": "test_instance.boop[1]: Plan to create",
"@module": "terraform.ui",
"type": "planned_change",
"change": map[string]interface{}{
"action": "create",
"resource": map[string]interface{}{
"addr": `test_instance.boop[1]`,
"implied_provider": "test",
"module": "",
"resource": `test_instance.boop[1]`,
"resource_key": float64(1),
"resource_name": "boop",
"resource_type": "test_instance",
},
},
},
cli: Add JSON logs for operations commands
2021-02-23 16:16:09 +01:00
}
testJSONViewOutputEquals(t, done(t).Stdout(), want)
}