pulumi/pkg/resource/deploy/step_test.go

1251 lines
36 KiB
Go
Raw Normal View History

// Copyright 2016-2023, Pulumi Corporation.
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
package deploy
import (
"context"
"errors"
"testing"
"github.com/pulumi/pulumi/pkg/v3/display"
"github.com/pulumi/pulumi/pkg/v3/resource/deploy/deploytest"
"github.com/pulumi/pulumi/pkg/v3/util/gsync"
"github.com/pulumi/pulumi/sdk/v3/go/common/diag/colors"
"github.com/pulumi/pulumi/sdk/v3/go/common/resource"
"github.com/pulumi/pulumi/sdk/v3/go/common/resource/plugin"
"github.com/pulumi/pulumi/sdk/v3/go/common/resource/urn"
"github.com/pulumi/pulumi/sdk/v3/go/common/tokens"
"github.com/stretchr/testify/assert"
)
func TestRawPrefix(t *testing.T) {
t.Parallel()
tests := []struct {
name string
op display.StepOp
want string
}{
{name: "Same", op: OpSame, want: " "},
{name: "Create", op: OpCreate, want: "+ "},
{name: "Delete", op: OpDelete, want: "- "},
{name: "Update", op: OpUpdate, want: "~ "},
{name: "Replace", op: OpReplace, want: "+-"},
{name: "CreateReplacement", op: OpCreateReplacement, want: "++"},
{name: "DeleteReplaced", op: OpDeleteReplaced, want: "--"},
{name: "Read", op: OpRead, want: "> "},
{name: "ReadReplacement", op: OpReadReplacement, want: ">>"},
{name: "Refresh", op: OpRefresh, want: "~ "},
{name: "ReadDiscard", op: OpReadDiscard, want: "< "},
{name: "DiscardReplaced", op: OpDiscardReplaced, want: "<<"},
{name: "Import", op: OpImport, want: "= "},
{name: "ImportReplacement", op: OpImportReplacement, want: "=>"},
}
for _, tt := range tests {
tt := tt
t.Run(tt.name, func(t *testing.T) {
t.Parallel()
assert.Equal(t, tt.want, RawPrefix(tt.op))
})
}
t.Run("panics on unknown", func(t *testing.T) {
t.Parallel()
assert.Panics(t, func() {
RawPrefix("not-a-real-operation")
})
})
}
func TestPastTense(t *testing.T) {
t.Parallel()
tests := []struct {
name string
op display.StepOp
want string
}{
{"Same", OpSame, "samed"},
{"Create", OpCreate, "created"},
{"Replace", OpReplace, "replaced"},
{"Update", OpUpdate, "updated"},
// TODO(dixler) consider fixing this.
{"CreateReplacement", OpCreateReplacement, "create-replacementd"},
{"ReadReplacement", OpReadReplacement, "read-replacementd"},
{"Refresh", OpRefresh, "refreshed"},
{"Read", OpRead, "read"},
{"ReadDiscard", OpReadDiscard, "discarded"},
{"DiscardReplaced", OpDiscardReplaced, "discarded"},
{"Delete", OpDelete, "deleted"},
{"DeleteReplaced", OpDeleteReplaced, "deleted"},
{"Import", OpImport, "imported"},
{"ImportReplacement", OpImportReplacement, "imported"},
}
for _, tt := range tests {
tt := tt
t.Run(tt.name, func(t *testing.T) {
t.Parallel()
assert.Equal(t, tt.want, PastTense(tt.op))
})
}
t.Run("panics on unknown", func(t *testing.T) {
t.Parallel()
assert.Panics(t, func() {
PastTense("not-a-real-operation")
})
})
}
func TestSameStep(t *testing.T) {
t.Parallel()
t.Run("Apply", func(t *testing.T) {
t.Parallel()
t.Run("bad provider state for resource", func(t *testing.T) {
t.Parallel()
s := &SameStep{
deployment: &Deployment{
opts: &Options{
DryRun: true,
},
},
old: &resource.State{
URN: "urn:pulumi:stack::project::type::foo",
},
new: &resource.State{
URN: "urn:pulumi:stack::project::type::foo",
Type: "pulumi:providers:some-provider",
},
}
_, _, err := s.Apply()
assert.ErrorContains(t, err, "bad provider state for resource")
})
})
}
func TestCreateStep(t *testing.T) {
t.Parallel()
t.Run("Apply", func(t *testing.T) {
t.Parallel()
t.Run("custom", func(t *testing.T) {
t.Parallel()
t.Run("error getting provider", func(t *testing.T) {
t.Parallel()
s := &CreateStep{
deployment: &Deployment{
opts: &Options{
DryRun: true,
},
},
new: &resource.State{
Custom: true,
// Use denydefaultprovider ID to ensure failure.
Provider: "urn:pulumi:stack::project::pulumi:providers:aws::default_5_42_0::denydefaultprovider",
},
}
status, _, err := s.Apply()
assert.ErrorContains(t, err, "Default provider for 'default_5_42_0' disabled.")
assert.Equal(t, resource.StatusOK, status)
})
t.Run("error in create", func(t *testing.T) {
t.Parallel()
expectedErr := errors.New("expected error")
var createCalled bool
s := &CreateStep{
new: &resource.State{
Custom: true,
},
Clean up deployment options (#16357) # Description There are a number of parts of the deployment process that require context about and configuration for the operation being executed. For instance: * Source evaluation -- evaluating programs in order to emit resource registrations * Step generation -- processing resource registrations in order to generate steps (create this, update that, delete the other, etc.) * Step execution -- executing steps in order to action a deployment. Presently, these pieces all take some form of `Options` struct or pass explicit arguments. This is problematic for a couple of reasons: * It could be possible for different parts of the codebase to end up operating in different contexts/with different configurations, whether due to different values being passed explicitly or due to missed copying/instantiation. * Some parts need less context/configuration than others, but still accept full `Options`, making it hard to discern what information is actually necessary in any given part of the process. This commit attempts to clean things up by moving deployment options directly into the `Deployment` itself. Since step generation and execution already refer to a `Deployment`, they get a consistent view of the options for free. For source evaluation, we introduce an `EvalSourceOptions` struct for configuring just the options necessary there. At the top level, the engine configures a single set of options to flow through the deployment steps later on. As part of this work, a few other things have been changed: * Preview/dry-run parameters have been incorporated into options. This lets up lop off another argument and mitigate a bit of "boolean blindness". We don't appear to flip this flag within a deployment process (indeed, all options seem to be immutable) and so having it as a separate flag doesn't seem to buy us anything. * Several methods representing parts of the deployment process have lost arguments in favour of state that is already being carried on (or can be carried on) their receiver. For instance, `deployment.run` no longer takes actions or preview configuration. While doing so means that a `deployment` could be run multiple times with different actions/preview arguments, we don't currently exploit this fact anywhere, so moving this state to the point of construction both simplifies things considerably and reduces the possibility for error (e.g. passing different values of `preview` when instantiating a `deployment` and subsequently calling `run`). * Event handlers have been split out of the options object and attached to `Deployment` separately. This means we can talk about options at a higher level without having to `nil` out/worry about this field and mutate it correctly later on. * Options are no longer mutated during deployment. Presently there appears to be only one case of this -- when handling `ContinueOnError` in the presence of `IgnoreChanges` (e.g. when performing a refresh). This case has been refactored so that the mutation is no longer necessary. # Notes * This change is in preparation for #16146, where we'd like to add an environment variable to control behaviour and having a single unified `Options` struct would make it easier to pass this configuration down with introducing (more) global state into deployments. Indeed, this change should make it easier to factor global state into `Options` so that it can be controlled and tested more easily/is less susceptible to bugs, race conditions, etc. * I've tweaked/extended some comments while I'm here and have learned things the hard way (e.g. `Refresh` vs `isRefresh`). Feedback welcome on this if we'd rather not conflate. * This change does mean that if in future we wanted e.g. to be able to run a `Deployment` in multiple different ways with multiple sets of actions, we'd have to refactor. Pushing state to the point of object construction reduces the flexibility of the code. However, since we are not presently using that flexibility (nor is there an obvious [to my mind] use case in the near future), this seems like a good trade-off to guard against bugs/make it simpler to move that state around. * I've left some other review comments in the code around questions/changes that might be a bad idea; happy to receive feedback on it all though!
2024-06-11 13:37:57 +00:00
deployment: &Deployment{
opts: &Options{
DryRun: true,
},
Clean up deployment options (#16357) # Description There are a number of parts of the deployment process that require context about and configuration for the operation being executed. For instance: * Source evaluation -- evaluating programs in order to emit resource registrations * Step generation -- processing resource registrations in order to generate steps (create this, update that, delete the other, etc.) * Step execution -- executing steps in order to action a deployment. Presently, these pieces all take some form of `Options` struct or pass explicit arguments. This is problematic for a couple of reasons: * It could be possible for different parts of the codebase to end up operating in different contexts/with different configurations, whether due to different values being passed explicitly or due to missed copying/instantiation. * Some parts need less context/configuration than others, but still accept full `Options`, making it hard to discern what information is actually necessary in any given part of the process. This commit attempts to clean things up by moving deployment options directly into the `Deployment` itself. Since step generation and execution already refer to a `Deployment`, they get a consistent view of the options for free. For source evaluation, we introduce an `EvalSourceOptions` struct for configuring just the options necessary there. At the top level, the engine configures a single set of options to flow through the deployment steps later on. As part of this work, a few other things have been changed: * Preview/dry-run parameters have been incorporated into options. This lets up lop off another argument and mitigate a bit of "boolean blindness". We don't appear to flip this flag within a deployment process (indeed, all options seem to be immutable) and so having it as a separate flag doesn't seem to buy us anything. * Several methods representing parts of the deployment process have lost arguments in favour of state that is already being carried on (or can be carried on) their receiver. For instance, `deployment.run` no longer takes actions or preview configuration. While doing so means that a `deployment` could be run multiple times with different actions/preview arguments, we don't currently exploit this fact anywhere, so moving this state to the point of construction both simplifies things considerably and reduces the possibility for error (e.g. passing different values of `preview` when instantiating a `deployment` and subsequently calling `run`). * Event handlers have been split out of the options object and attached to `Deployment` separately. This means we can talk about options at a higher level without having to `nil` out/worry about this field and mutate it correctly later on. * Options are no longer mutated during deployment. Presently there appears to be only one case of this -- when handling `ContinueOnError` in the presence of `IgnoreChanges` (e.g. when performing a refresh). This case has been refactored so that the mutation is no longer necessary. # Notes * This change is in preparation for #16146, where we'd like to add an environment variable to control behaviour and having a single unified `Options` struct would make it easier to pass this configuration down with introducing (more) global state into deployments. Indeed, this change should make it easier to factor global state into `Options` so that it can be controlled and tested more easily/is less susceptible to bugs, race conditions, etc. * I've tweaked/extended some comments while I'm here and have learned things the hard way (e.g. `Refresh` vs `isRefresh`). Feedback welcome on this if we'd rather not conflate. * This change does mean that if in future we wanted e.g. to be able to run a `Deployment` in multiple different ways with multiple sets of actions, we'd have to refactor. Pushing state to the point of object construction reduces the flexibility of the code. However, since we are not presently using that flexibility (nor is there an obvious [to my mind] use case in the near future), this seems like a good trade-off to guard against bugs/make it simpler to move that state around. * I've left some other review comments in the code around questions/changes that might be a bad idea; happy to receive feedback on it all though!
2024-06-11 13:37:57 +00:00
},
provider: &deploytest.Provider{
CreateF: func(context.Context, plugin.CreateRequest) (plugin.CreateResponse, error) {
createCalled = true
return plugin.CreateResponse{}, expectedErr
},
},
}
status, _, err := s.Apply()
assert.ErrorIs(t, err, expectedErr)
assert.True(t, createCalled)
assert.Equal(t, resource.StatusOK, status)
})
t.Run("handle InitError", func(t *testing.T) {
t.Parallel()
s := &CreateStep{
new: &resource.State{
Custom: true,
},
Clean up deployment options (#16357) # Description There are a number of parts of the deployment process that require context about and configuration for the operation being executed. For instance: * Source evaluation -- evaluating programs in order to emit resource registrations * Step generation -- processing resource registrations in order to generate steps (create this, update that, delete the other, etc.) * Step execution -- executing steps in order to action a deployment. Presently, these pieces all take some form of `Options` struct or pass explicit arguments. This is problematic for a couple of reasons: * It could be possible for different parts of the codebase to end up operating in different contexts/with different configurations, whether due to different values being passed explicitly or due to missed copying/instantiation. * Some parts need less context/configuration than others, but still accept full `Options`, making it hard to discern what information is actually necessary in any given part of the process. This commit attempts to clean things up by moving deployment options directly into the `Deployment` itself. Since step generation and execution already refer to a `Deployment`, they get a consistent view of the options for free. For source evaluation, we introduce an `EvalSourceOptions` struct for configuring just the options necessary there. At the top level, the engine configures a single set of options to flow through the deployment steps later on. As part of this work, a few other things have been changed: * Preview/dry-run parameters have been incorporated into options. This lets up lop off another argument and mitigate a bit of "boolean blindness". We don't appear to flip this flag within a deployment process (indeed, all options seem to be immutable) and so having it as a separate flag doesn't seem to buy us anything. * Several methods representing parts of the deployment process have lost arguments in favour of state that is already being carried on (or can be carried on) their receiver. For instance, `deployment.run` no longer takes actions or preview configuration. While doing so means that a `deployment` could be run multiple times with different actions/preview arguments, we don't currently exploit this fact anywhere, so moving this state to the point of construction both simplifies things considerably and reduces the possibility for error (e.g. passing different values of `preview` when instantiating a `deployment` and subsequently calling `run`). * Event handlers have been split out of the options object and attached to `Deployment` separately. This means we can talk about options at a higher level without having to `nil` out/worry about this field and mutate it correctly later on. * Options are no longer mutated during deployment. Presently there appears to be only one case of this -- when handling `ContinueOnError` in the presence of `IgnoreChanges` (e.g. when performing a refresh). This case has been refactored so that the mutation is no longer necessary. # Notes * This change is in preparation for #16146, where we'd like to add an environment variable to control behaviour and having a single unified `Options` struct would make it easier to pass this configuration down with introducing (more) global state into deployments. Indeed, this change should make it easier to factor global state into `Options` so that it can be controlled and tested more easily/is less susceptible to bugs, race conditions, etc. * I've tweaked/extended some comments while I'm here and have learned things the hard way (e.g. `Refresh` vs `isRefresh`). Feedback welcome on this if we'd rather not conflate. * This change does mean that if in future we wanted e.g. to be able to run a `Deployment` in multiple different ways with multiple sets of actions, we'd have to refactor. Pushing state to the point of object construction reduces the flexibility of the code. However, since we are not presently using that flexibility (nor is there an obvious [to my mind] use case in the near future), this seems like a good trade-off to guard against bugs/make it simpler to move that state around. * I've left some other review comments in the code around questions/changes that might be a bad idea; happy to receive feedback on it all though!
2024-06-11 13:37:57 +00:00
deployment: &Deployment{
opts: &Options{
DryRun: true,
},
Clean up deployment options (#16357) # Description There are a number of parts of the deployment process that require context about and configuration for the operation being executed. For instance: * Source evaluation -- evaluating programs in order to emit resource registrations * Step generation -- processing resource registrations in order to generate steps (create this, update that, delete the other, etc.) * Step execution -- executing steps in order to action a deployment. Presently, these pieces all take some form of `Options` struct or pass explicit arguments. This is problematic for a couple of reasons: * It could be possible for different parts of the codebase to end up operating in different contexts/with different configurations, whether due to different values being passed explicitly or due to missed copying/instantiation. * Some parts need less context/configuration than others, but still accept full `Options`, making it hard to discern what information is actually necessary in any given part of the process. This commit attempts to clean things up by moving deployment options directly into the `Deployment` itself. Since step generation and execution already refer to a `Deployment`, they get a consistent view of the options for free. For source evaluation, we introduce an `EvalSourceOptions` struct for configuring just the options necessary there. At the top level, the engine configures a single set of options to flow through the deployment steps later on. As part of this work, a few other things have been changed: * Preview/dry-run parameters have been incorporated into options. This lets up lop off another argument and mitigate a bit of "boolean blindness". We don't appear to flip this flag within a deployment process (indeed, all options seem to be immutable) and so having it as a separate flag doesn't seem to buy us anything. * Several methods representing parts of the deployment process have lost arguments in favour of state that is already being carried on (or can be carried on) their receiver. For instance, `deployment.run` no longer takes actions or preview configuration. While doing so means that a `deployment` could be run multiple times with different actions/preview arguments, we don't currently exploit this fact anywhere, so moving this state to the point of construction both simplifies things considerably and reduces the possibility for error (e.g. passing different values of `preview` when instantiating a `deployment` and subsequently calling `run`). * Event handlers have been split out of the options object and attached to `Deployment` separately. This means we can talk about options at a higher level without having to `nil` out/worry about this field and mutate it correctly later on. * Options are no longer mutated during deployment. Presently there appears to be only one case of this -- when handling `ContinueOnError` in the presence of `IgnoreChanges` (e.g. when performing a refresh). This case has been refactored so that the mutation is no longer necessary. # Notes * This change is in preparation for #16146, where we'd like to add an environment variable to control behaviour and having a single unified `Options` struct would make it easier to pass this configuration down with introducing (more) global state into deployments. Indeed, this change should make it easier to factor global state into `Options` so that it can be controlled and tested more easily/is less susceptible to bugs, race conditions, etc. * I've tweaked/extended some comments while I'm here and have learned things the hard way (e.g. `Refresh` vs `isRefresh`). Feedback welcome on this if we'd rather not conflate. * This change does mean that if in future we wanted e.g. to be able to run a `Deployment` in multiple different ways with multiple sets of actions, we'd have to refactor. Pushing state to the point of object construction reduces the flexibility of the code. However, since we are not presently using that flexibility (nor is there an obvious [to my mind] use case in the near future), this seems like a good trade-off to guard against bugs/make it simpler to move that state around. * I've left some other review comments in the code around questions/changes that might be a bad idea; happy to receive feedback on it all though!
2024-06-11 13:37:57 +00:00
},
provider: &deploytest.Provider{
CreateF: func(context.Context, plugin.CreateRequest) (plugin.CreateResponse, error) {
return plugin.CreateResponse{
Status: resource.StatusPartialFailure,
}, &plugin.InitError{
Reasons: []string{
"intentional error",
},
}
},
},
}
status, _, err := s.Apply()
assert.ErrorContains(t, err, "intentional error")
assert.Len(t, s.new.InitErrors, 1)
assert.Equal(t, resource.StatusPartialFailure, status)
})
t.Run("error create no ID", func(t *testing.T) {
t.Parallel()
s := &CreateStep{
new: &resource.State{
Custom: true,
},
Clean up deployment options (#16357) # Description There are a number of parts of the deployment process that require context about and configuration for the operation being executed. For instance: * Source evaluation -- evaluating programs in order to emit resource registrations * Step generation -- processing resource registrations in order to generate steps (create this, update that, delete the other, etc.) * Step execution -- executing steps in order to action a deployment. Presently, these pieces all take some form of `Options` struct or pass explicit arguments. This is problematic for a couple of reasons: * It could be possible for different parts of the codebase to end up operating in different contexts/with different configurations, whether due to different values being passed explicitly or due to missed copying/instantiation. * Some parts need less context/configuration than others, but still accept full `Options`, making it hard to discern what information is actually necessary in any given part of the process. This commit attempts to clean things up by moving deployment options directly into the `Deployment` itself. Since step generation and execution already refer to a `Deployment`, they get a consistent view of the options for free. For source evaluation, we introduce an `EvalSourceOptions` struct for configuring just the options necessary there. At the top level, the engine configures a single set of options to flow through the deployment steps later on. As part of this work, a few other things have been changed: * Preview/dry-run parameters have been incorporated into options. This lets up lop off another argument and mitigate a bit of "boolean blindness". We don't appear to flip this flag within a deployment process (indeed, all options seem to be immutable) and so having it as a separate flag doesn't seem to buy us anything. * Several methods representing parts of the deployment process have lost arguments in favour of state that is already being carried on (or can be carried on) their receiver. For instance, `deployment.run` no longer takes actions or preview configuration. While doing so means that a `deployment` could be run multiple times with different actions/preview arguments, we don't currently exploit this fact anywhere, so moving this state to the point of construction both simplifies things considerably and reduces the possibility for error (e.g. passing different values of `preview` when instantiating a `deployment` and subsequently calling `run`). * Event handlers have been split out of the options object and attached to `Deployment` separately. This means we can talk about options at a higher level without having to `nil` out/worry about this field and mutate it correctly later on. * Options are no longer mutated during deployment. Presently there appears to be only one case of this -- when handling `ContinueOnError` in the presence of `IgnoreChanges` (e.g. when performing a refresh). This case has been refactored so that the mutation is no longer necessary. # Notes * This change is in preparation for #16146, where we'd like to add an environment variable to control behaviour and having a single unified `Options` struct would make it easier to pass this configuration down with introducing (more) global state into deployments. Indeed, this change should make it easier to factor global state into `Options` so that it can be controlled and tested more easily/is less susceptible to bugs, race conditions, etc. * I've tweaked/extended some comments while I'm here and have learned things the hard way (e.g. `Refresh` vs `isRefresh`). Feedback welcome on this if we'd rather not conflate. * This change does mean that if in future we wanted e.g. to be able to run a `Deployment` in multiple different ways with multiple sets of actions, we'd have to refactor. Pushing state to the point of object construction reduces the flexibility of the code. However, since we are not presently using that flexibility (nor is there an obvious [to my mind] use case in the near future), this seems like a good trade-off to guard against bugs/make it simpler to move that state around. * I've left some other review comments in the code around questions/changes that might be a bad idea; happy to receive feedback on it all though!
2024-06-11 13:37:57 +00:00
deployment: &Deployment{
opts: &Options{},
},
provider: &deploytest.Provider{
CreateF: func(context.Context, plugin.CreateRequest) (plugin.CreateResponse, error) {
return plugin.CreateResponse{}, nil
},
},
}
status, _, err := s.Apply()
assert.ErrorContains(t, err, "provider did not return an ID from Create")
assert.Equal(t, resource.StatusOK, status)
})
})
})
}
func TestDeleteStep(t *testing.T) {
t.Parallel()
t.Run("isDeletedWith", func(t *testing.T) {
t.Parallel()
otherDeletions := map[resource.URN]bool{
"false-key": false,
"true-key": true,
}
assert.False(t, isDeletedWith("", otherDeletions))
assert.False(t, isDeletedWith("does-not-exist", otherDeletions))
assert.False(t, isDeletedWith("false-key", otherDeletions))
assert.True(t, isDeletedWith("true-key", otherDeletions))
})
t.Run("Apply", func(t *testing.T) {
t.Parallel()
t.Run("custom", func(t *testing.T) {
t.Parallel()
t.Run("error getting provider", func(t *testing.T) {
t.Parallel()
s := &DeleteStep{
deployment: &Deployment{
opts: &Options{
DryRun: false,
},
},
old: &resource.State{
Custom: true,
// Use denydefaultprovider ID to ensure failure.
Provider: "urn:pulumi:stack::project::pulumi:providers:aws::default_5_42_0::denydefaultprovider",
},
}
status, _, err := s.Apply()
assert.ErrorContains(t, err, "Default provider for 'default_5_42_0' disabled.")
assert.Equal(t, resource.StatusOK, status)
})
})
})
}
func TestRemovePendingReplaceStep(t *testing.T) {
t.Parallel()
t.Run("NewRemovePendingReplaceStep", func(t *testing.T) {
t.Parallel()
t.Run("panics on old=nil", func(t *testing.T) {
t.Parallel()
assert.Panics(t, func() {
NewRemovePendingReplaceStep(nil, nil)
})
})
t.Run("panics if not old.PendingReplacement", func(t *testing.T) {
t.Parallel()
assert.Panics(t, func() {
NewRemovePendingReplaceStep(nil, &resource.State{
PendingReplacement: false,
})
})
})
})
t.Run("Op", func(t *testing.T) {
t.Parallel()
s := NewRemovePendingReplaceStep(nil, &resource.State{
PendingReplacement: true,
})
assert.Equal(t, OpRemovePendingReplace, s.Op())
})
t.Run("Deployment", func(t *testing.T) {
t.Parallel()
d := &Deployment{}
s := NewRemovePendingReplaceStep(d, &resource.State{
Type: "expected-value",
PendingReplacement: true,
})
assert.Equal(t, d, s.Deployment())
})
t.Run("Type", func(t *testing.T) {
t.Parallel()
s := NewRemovePendingReplaceStep(nil, &resource.State{
Type: "expected-value",
PendingReplacement: true,
})
assert.Equal(t, tokens.Type("expected-value"), s.Type())
})
t.Run("Provider", func(t *testing.T) {
t.Parallel()
s := NewRemovePendingReplaceStep(nil, &resource.State{
Provider: "expected-value",
PendingReplacement: true,
})
assert.Equal(t, "expected-value", s.Provider())
})
t.Run("URN", func(t *testing.T) {
t.Parallel()
s := NewRemovePendingReplaceStep(nil, &resource.State{
URN: "expected-value",
PendingReplacement: true,
})
assert.Equal(t, resource.URN("expected-value"), s.URN())
})
t.Run("Old", func(t *testing.T) {
t.Parallel()
old := &resource.State{
URN: "expected-value",
PendingReplacement: true,
}
s := NewRemovePendingReplaceStep(nil, old)
assert.Equal(t, old, s.Old())
})
t.Run("New", func(t *testing.T) {
t.Parallel()
s := NewRemovePendingReplaceStep(nil, &resource.State{
PendingReplacement: true,
})
assert.Equal(t, (*resource.State)(nil), s.New())
})
t.Run("Res", func(t *testing.T) {
t.Parallel()
old := &resource.State{
PendingReplacement: true,
}
s := NewRemovePendingReplaceStep(nil, old)
assert.Equal(t, old, s.Res())
})
t.Run("Logical", func(t *testing.T) {
t.Parallel()
s := NewRemovePendingReplaceStep(nil, &resource.State{
PendingReplacement: true,
})
assert.False(t, s.Logical())
})
t.Run("Apply", func(t *testing.T) {
t.Parallel()
d := &Deployment{
opts: &Options{
DryRun: true,
},
}
s := NewRemovePendingReplaceStep(d, &resource.State{
PendingReplacement: true,
})
status, _, err := s.Apply()
assert.NoError(t, err)
assert.Equal(t, resource.StatusOK, status)
})
}
func TestUpdateStep(t *testing.T) {
t.Parallel()
t.Run("Apply", func(t *testing.T) {
t.Parallel()
t.Run("error getting provider", func(t *testing.T) {
t.Parallel()
s := &UpdateStep{
deployment: &Deployment{
opts: &Options{
DryRun: true,
},
},
old: &resource.State{},
new: &resource.State{
Custom: true,
// Use denydefaultprovider ID to ensure failure.
Provider: "urn:pulumi:stack::project::pulumi:providers:aws::default_5_42_0::denydefaultprovider",
},
}
status, _, err := s.Apply()
assert.ErrorContains(t, err, "Default provider for 'default_5_42_0' disabled.")
assert.Equal(t, resource.StatusOK, status)
})
t.Run("failure in provider", func(t *testing.T) {
t.Parallel()
expectedErr := errors.New("expected error")
s := &UpdateStep{
old: &resource.State{},
new: &resource.State{
Custom: true,
// Use denydefaultprovider ID to ensure failure.
Provider: "urn:pulumi:stack::project::pulumi:providers:aws::default_5_42_0::denydefaultprovider",
},
Clean up deployment options (#16357) # Description There are a number of parts of the deployment process that require context about and configuration for the operation being executed. For instance: * Source evaluation -- evaluating programs in order to emit resource registrations * Step generation -- processing resource registrations in order to generate steps (create this, update that, delete the other, etc.) * Step execution -- executing steps in order to action a deployment. Presently, these pieces all take some form of `Options` struct or pass explicit arguments. This is problematic for a couple of reasons: * It could be possible for different parts of the codebase to end up operating in different contexts/with different configurations, whether due to different values being passed explicitly or due to missed copying/instantiation. * Some parts need less context/configuration than others, but still accept full `Options`, making it hard to discern what information is actually necessary in any given part of the process. This commit attempts to clean things up by moving deployment options directly into the `Deployment` itself. Since step generation and execution already refer to a `Deployment`, they get a consistent view of the options for free. For source evaluation, we introduce an `EvalSourceOptions` struct for configuring just the options necessary there. At the top level, the engine configures a single set of options to flow through the deployment steps later on. As part of this work, a few other things have been changed: * Preview/dry-run parameters have been incorporated into options. This lets up lop off another argument and mitigate a bit of "boolean blindness". We don't appear to flip this flag within a deployment process (indeed, all options seem to be immutable) and so having it as a separate flag doesn't seem to buy us anything. * Several methods representing parts of the deployment process have lost arguments in favour of state that is already being carried on (or can be carried on) their receiver. For instance, `deployment.run` no longer takes actions or preview configuration. While doing so means that a `deployment` could be run multiple times with different actions/preview arguments, we don't currently exploit this fact anywhere, so moving this state to the point of construction both simplifies things considerably and reduces the possibility for error (e.g. passing different values of `preview` when instantiating a `deployment` and subsequently calling `run`). * Event handlers have been split out of the options object and attached to `Deployment` separately. This means we can talk about options at a higher level without having to `nil` out/worry about this field and mutate it correctly later on. * Options are no longer mutated during deployment. Presently there appears to be only one case of this -- when handling `ContinueOnError` in the presence of `IgnoreChanges` (e.g. when performing a refresh). This case has been refactored so that the mutation is no longer necessary. # Notes * This change is in preparation for #16146, where we'd like to add an environment variable to control behaviour and having a single unified `Options` struct would make it easier to pass this configuration down with introducing (more) global state into deployments. Indeed, this change should make it easier to factor global state into `Options` so that it can be controlled and tested more easily/is less susceptible to bugs, race conditions, etc. * I've tweaked/extended some comments while I'm here and have learned things the hard way (e.g. `Refresh` vs `isRefresh`). Feedback welcome on this if we'd rather not conflate. * This change does mean that if in future we wanted e.g. to be able to run a `Deployment` in multiple different ways with multiple sets of actions, we'd have to refactor. Pushing state to the point of object construction reduces the flexibility of the code. However, since we are not presently using that flexibility (nor is there an obvious [to my mind] use case in the near future), this seems like a good trade-off to guard against bugs/make it simpler to move that state around. * I've left some other review comments in the code around questions/changes that might be a bad idea; happy to receive feedback on it all though!
2024-06-11 13:37:57 +00:00
deployment: &Deployment{
opts: &Options{
DryRun: true,
},
Clean up deployment options (#16357) # Description There are a number of parts of the deployment process that require context about and configuration for the operation being executed. For instance: * Source evaluation -- evaluating programs in order to emit resource registrations * Step generation -- processing resource registrations in order to generate steps (create this, update that, delete the other, etc.) * Step execution -- executing steps in order to action a deployment. Presently, these pieces all take some form of `Options` struct or pass explicit arguments. This is problematic for a couple of reasons: * It could be possible for different parts of the codebase to end up operating in different contexts/with different configurations, whether due to different values being passed explicitly or due to missed copying/instantiation. * Some parts need less context/configuration than others, but still accept full `Options`, making it hard to discern what information is actually necessary in any given part of the process. This commit attempts to clean things up by moving deployment options directly into the `Deployment` itself. Since step generation and execution already refer to a `Deployment`, they get a consistent view of the options for free. For source evaluation, we introduce an `EvalSourceOptions` struct for configuring just the options necessary there. At the top level, the engine configures a single set of options to flow through the deployment steps later on. As part of this work, a few other things have been changed: * Preview/dry-run parameters have been incorporated into options. This lets up lop off another argument and mitigate a bit of "boolean blindness". We don't appear to flip this flag within a deployment process (indeed, all options seem to be immutable) and so having it as a separate flag doesn't seem to buy us anything. * Several methods representing parts of the deployment process have lost arguments in favour of state that is already being carried on (or can be carried on) their receiver. For instance, `deployment.run` no longer takes actions or preview configuration. While doing so means that a `deployment` could be run multiple times with different actions/preview arguments, we don't currently exploit this fact anywhere, so moving this state to the point of construction both simplifies things considerably and reduces the possibility for error (e.g. passing different values of `preview` when instantiating a `deployment` and subsequently calling `run`). * Event handlers have been split out of the options object and attached to `Deployment` separately. This means we can talk about options at a higher level without having to `nil` out/worry about this field and mutate it correctly later on. * Options are no longer mutated during deployment. Presently there appears to be only one case of this -- when handling `ContinueOnError` in the presence of `IgnoreChanges` (e.g. when performing a refresh). This case has been refactored so that the mutation is no longer necessary. # Notes * This change is in preparation for #16146, where we'd like to add an environment variable to control behaviour and having a single unified `Options` struct would make it easier to pass this configuration down with introducing (more) global state into deployments. Indeed, this change should make it easier to factor global state into `Options` so that it can be controlled and tested more easily/is less susceptible to bugs, race conditions, etc. * I've tweaked/extended some comments while I'm here and have learned things the hard way (e.g. `Refresh` vs `isRefresh`). Feedback welcome on this if we'd rather not conflate. * This change does mean that if in future we wanted e.g. to be able to run a `Deployment` in multiple different ways with multiple sets of actions, we'd have to refactor. Pushing state to the point of object construction reduces the flexibility of the code. However, since we are not presently using that flexibility (nor is there an obvious [to my mind] use case in the near future), this seems like a good trade-off to guard against bugs/make it simpler to move that state around. * I've left some other review comments in the code around questions/changes that might be a bad idea; happy to receive feedback on it all though!
2024-06-11 13:37:57 +00:00
},
provider: &deploytest.Provider{
UpdateF: func(context.Context, plugin.UpdateRequest) (plugin.UpdateResponse, error) {
return plugin.UpdateResponse{}, expectedErr
},
},
}
status, _, err := s.Apply()
assert.ErrorIs(t, err, expectedErr)
assert.Equal(t, resource.StatusOK, status)
})
t.Run("partial failure in provider", func(t *testing.T) {
t.Parallel()
s := &UpdateStep{
old: &resource.State{},
new: &resource.State{
Custom: true,
// Use denydefaultprovider ID to ensure failure.
Provider: "urn:pulumi:stack::project::pulumi:providers:aws::default_5_42_0::denydefaultprovider",
},
Clean up deployment options (#16357) # Description There are a number of parts of the deployment process that require context about and configuration for the operation being executed. For instance: * Source evaluation -- evaluating programs in order to emit resource registrations * Step generation -- processing resource registrations in order to generate steps (create this, update that, delete the other, etc.) * Step execution -- executing steps in order to action a deployment. Presently, these pieces all take some form of `Options` struct or pass explicit arguments. This is problematic for a couple of reasons: * It could be possible for different parts of the codebase to end up operating in different contexts/with different configurations, whether due to different values being passed explicitly or due to missed copying/instantiation. * Some parts need less context/configuration than others, but still accept full `Options`, making it hard to discern what information is actually necessary in any given part of the process. This commit attempts to clean things up by moving deployment options directly into the `Deployment` itself. Since step generation and execution already refer to a `Deployment`, they get a consistent view of the options for free. For source evaluation, we introduce an `EvalSourceOptions` struct for configuring just the options necessary there. At the top level, the engine configures a single set of options to flow through the deployment steps later on. As part of this work, a few other things have been changed: * Preview/dry-run parameters have been incorporated into options. This lets up lop off another argument and mitigate a bit of "boolean blindness". We don't appear to flip this flag within a deployment process (indeed, all options seem to be immutable) and so having it as a separate flag doesn't seem to buy us anything. * Several methods representing parts of the deployment process have lost arguments in favour of state that is already being carried on (or can be carried on) their receiver. For instance, `deployment.run` no longer takes actions or preview configuration. While doing so means that a `deployment` could be run multiple times with different actions/preview arguments, we don't currently exploit this fact anywhere, so moving this state to the point of construction both simplifies things considerably and reduces the possibility for error (e.g. passing different values of `preview` when instantiating a `deployment` and subsequently calling `run`). * Event handlers have been split out of the options object and attached to `Deployment` separately. This means we can talk about options at a higher level without having to `nil` out/worry about this field and mutate it correctly later on. * Options are no longer mutated during deployment. Presently there appears to be only one case of this -- when handling `ContinueOnError` in the presence of `IgnoreChanges` (e.g. when performing a refresh). This case has been refactored so that the mutation is no longer necessary. # Notes * This change is in preparation for #16146, where we'd like to add an environment variable to control behaviour and having a single unified `Options` struct would make it easier to pass this configuration down with introducing (more) global state into deployments. Indeed, this change should make it easier to factor global state into `Options` so that it can be controlled and tested more easily/is less susceptible to bugs, race conditions, etc. * I've tweaked/extended some comments while I'm here and have learned things the hard way (e.g. `Refresh` vs `isRefresh`). Feedback welcome on this if we'd rather not conflate. * This change does mean that if in future we wanted e.g. to be able to run a `Deployment` in multiple different ways with multiple sets of actions, we'd have to refactor. Pushing state to the point of object construction reduces the flexibility of the code. However, since we are not presently using that flexibility (nor is there an obvious [to my mind] use case in the near future), this seems like a good trade-off to guard against bugs/make it simpler to move that state around. * I've left some other review comments in the code around questions/changes that might be a bad idea; happy to receive feedback on it all though!
2024-06-11 13:37:57 +00:00
deployment: &Deployment{
opts: &Options{
DryRun: true,
},
Clean up deployment options (#16357) # Description There are a number of parts of the deployment process that require context about and configuration for the operation being executed. For instance: * Source evaluation -- evaluating programs in order to emit resource registrations * Step generation -- processing resource registrations in order to generate steps (create this, update that, delete the other, etc.) * Step execution -- executing steps in order to action a deployment. Presently, these pieces all take some form of `Options` struct or pass explicit arguments. This is problematic for a couple of reasons: * It could be possible for different parts of the codebase to end up operating in different contexts/with different configurations, whether due to different values being passed explicitly or due to missed copying/instantiation. * Some parts need less context/configuration than others, but still accept full `Options`, making it hard to discern what information is actually necessary in any given part of the process. This commit attempts to clean things up by moving deployment options directly into the `Deployment` itself. Since step generation and execution already refer to a `Deployment`, they get a consistent view of the options for free. For source evaluation, we introduce an `EvalSourceOptions` struct for configuring just the options necessary there. At the top level, the engine configures a single set of options to flow through the deployment steps later on. As part of this work, a few other things have been changed: * Preview/dry-run parameters have been incorporated into options. This lets up lop off another argument and mitigate a bit of "boolean blindness". We don't appear to flip this flag within a deployment process (indeed, all options seem to be immutable) and so having it as a separate flag doesn't seem to buy us anything. * Several methods representing parts of the deployment process have lost arguments in favour of state that is already being carried on (or can be carried on) their receiver. For instance, `deployment.run` no longer takes actions or preview configuration. While doing so means that a `deployment` could be run multiple times with different actions/preview arguments, we don't currently exploit this fact anywhere, so moving this state to the point of construction both simplifies things considerably and reduces the possibility for error (e.g. passing different values of `preview` when instantiating a `deployment` and subsequently calling `run`). * Event handlers have been split out of the options object and attached to `Deployment` separately. This means we can talk about options at a higher level without having to `nil` out/worry about this field and mutate it correctly later on. * Options are no longer mutated during deployment. Presently there appears to be only one case of this -- when handling `ContinueOnError` in the presence of `IgnoreChanges` (e.g. when performing a refresh). This case has been refactored so that the mutation is no longer necessary. # Notes * This change is in preparation for #16146, where we'd like to add an environment variable to control behaviour and having a single unified `Options` struct would make it easier to pass this configuration down with introducing (more) global state into deployments. Indeed, this change should make it easier to factor global state into `Options` so that it can be controlled and tested more easily/is less susceptible to bugs, race conditions, etc. * I've tweaked/extended some comments while I'm here and have learned things the hard way (e.g. `Refresh` vs `isRefresh`). Feedback welcome on this if we'd rather not conflate. * This change does mean that if in future we wanted e.g. to be able to run a `Deployment` in multiple different ways with multiple sets of actions, we'd have to refactor. Pushing state to the point of object construction reduces the flexibility of the code. However, since we are not presently using that flexibility (nor is there an obvious [to my mind] use case in the near future), this seems like a good trade-off to guard against bugs/make it simpler to move that state around. * I've left some other review comments in the code around questions/changes that might be a bad idea; happy to receive feedback on it all though!
2024-06-11 13:37:57 +00:00
},
provider: &deploytest.Provider{
UpdateF: func(context.Context, plugin.UpdateRequest) (plugin.UpdateResponse, error) {
return plugin.UpdateResponse{
Properties: resource.PropertyMap{
"key": resource.NewStringProperty("expected-value"),
},
Status: resource.StatusPartialFailure,
}, &plugin.InitError{
Reasons: []string{
"intentional error",
},
}
},
},
}
status, _, err := s.Apply()
assert.ErrorContains(t, err, "intentional error")
assert.Equal(t, resource.StatusPartialFailure, status)
// News should be updated.
assert.Len(t, s.new.InitErrors, 1)
assert.Equal(t, resource.PropertyMap{
"key": resource.NewStringProperty("expected-value"),
}, s.new.Outputs)
})
})
}
func TestReplaceStep(t *testing.T) {
t.Parallel()
t.Run("Deployment", func(t *testing.T) {
t.Parallel()
d := &Deployment{}
s := ReplaceStep{deployment: d}
assert.Equal(t, d, s.Deployment())
})
}
func TestReadStep(t *testing.T) {
t.Parallel()
t.Run("Apply", func(t *testing.T) {
t.Parallel()
t.Run("error getting provider", func(t *testing.T) {
t.Parallel()
s := &ReadStep{
deployment: &Deployment{
opts: &Options{
DryRun: true,
},
},
old: &resource.State{},
new: &resource.State{
Custom: true,
// Use denydefaultprovider ID to ensure failure.
Provider: "urn:pulumi:stack::project::pulumi:providers:aws::default_5_42_0::denydefaultprovider",
},
}
status, _, err := s.Apply()
assert.ErrorContains(t, err, "Default provider for 'default_5_42_0' disabled.")
assert.Equal(t, resource.StatusOK, status)
})
t.Run("failure in provider", func(t *testing.T) {
t.Parallel()
expectedErr := errors.New("expected error")
s := &ReadStep{
old: &resource.State{},
new: &resource.State{
URN: "some-urn",
ID: "some-id",
Custom: true,
// Use denydefaultprovider ID to ensure failure.
Provider: "urn:pulumi:stack::project::pulumi:providers:aws::default_5_42_0::denydefaultprovider",
},
deployment: &Deployment{
opts: &Options{
DryRun: true,
},
},
provider: &deploytest.Provider{
ReadF: func(context.Context, plugin.ReadRequest) (plugin.ReadResponse, error) {
return plugin.ReadResponse{}, expectedErr
},
},
}
status, _, err := s.Apply()
assert.ErrorIs(t, err, expectedErr)
assert.Equal(t, resource.StatusOK, status)
})
t.Run("partial failure in provider", func(t *testing.T) {
t.Parallel()
s := &ReadStep{
old: &resource.State{},
new: &resource.State{
URN: "some-urn",
ID: "some-id",
Custom: true,
// Use denydefaultprovider ID to ensure failure.
Provider: "urn:pulumi:stack::project::pulumi:providers:aws::default_5_42_0::denydefaultprovider",
},
deployment: &Deployment{
opts: &Options{
DryRun: true,
},
},
provider: &deploytest.Provider{
ReadF: func(context.Context, plugin.ReadRequest) (plugin.ReadResponse, error) {
return plugin.ReadResponse{
ReadResult: plugin.ReadResult{
ID: "new-id",
Inputs: resource.PropertyMap{
"inputs-key": resource.NewStringProperty("expected-value"),
},
Outputs: resource.PropertyMap{
"outputs-key": resource.NewStringProperty("expected-value"),
},
},
Status: resource.StatusPartialFailure,
}, &plugin.InitError{
Reasons: []string{
"intentional error",
},
}
},
},
}
status, _, err := s.Apply()
assert.ErrorContains(t, err, "intentional error")
assert.Equal(t, resource.StatusPartialFailure, status)
// News should be updated.
assert.Len(t, s.new.InitErrors, 1)
assert.Equal(t, (resource.PropertyMap)(nil), s.new.Inputs)
assert.Equal(t, resource.PropertyMap{
"outputs-key": resource.NewStringProperty("expected-value"),
}, s.new.Outputs)
assert.Equal(t, resource.ID("new-id"), s.new.ID)
})
t.Run("unknown id", func(t *testing.T) {
t.Parallel()
s := &ReadStep{
deployment: &Deployment{
opts: &Options{
DryRun: true,
},
},
new: &resource.State{
ID: plugin.UnknownStringValue,
},
provider: &deploytest.Provider{
ReadF: func(context.Context, plugin.ReadRequest) (plugin.ReadResponse, error) {
panic("should not be called")
},
},
}
status, _, err := s.Apply()
assert.NoError(t, err)
assert.Equal(t, resource.StatusOK, status)
// News should be updated.
assert.Equal(t, resource.PropertyMap{}, s.new.Outputs)
})
})
}
Change `pulumi refresh` to report diff relative to desired state instead of relative to only output changes (#16146) Presently, the behaviour of diffing during refresh steps is incomplete, returning only an "output diff" that presents the changes in outputs. This commit changes refresh steps so that: * they compute a diff similar to the one that would be computed if a `preview` were run immediately after the refresh, which is more typically what users expect and want; and * `IgnoreChanges` resource options are respected when performing the new desired-state diffs, so that property additions or changes reported by a refresh can be ignored. In particular, `IgnoreChanges` can now be used to acknowledge that part or all of a resource may change in the provider, but the user is OK with this and doesn't want to be notified about it during a refresh. Importantly, this means that the diff won't be reported, but also that the changes won't be applied to state. The implementation covers the following: * A diff is computed using the inputs from the program and then inverting the result, since in the case of a refresh the diff is being driven by the provider side and not the program. This doesn't change what is stored back into the state, but it does produce a diff that is more aligned with the "true changes to the desired state". * `IgnoreChanges` resource options are now stored in state, so that this information can be used in refresh operations that do not have access to/run the program. * In the context of a refresh operation, `IgnoreChanges` applies to *both* input and output properties. This differs from the behaviour of a normal update operation, where `IgnoreChanges` only considers input properties. * The special `"*"` value for `IgnoreChanges` can be used to ignore all properties. It _also_ ignores the case where the resource cannot be found in the provider, and instead keeps the resource intact in state with its existing input and output properties. Because the program is not run for refresh operations, `IgnoreChanges` options must be applied separately before a refresh takes place. This can be accomplished using e.g. a `pulumi up` that applies the options prior to a refresh. We should investigate perhaps providing a `pulumi state set ...`-like CLI to make these sorts of changes directly to a state. For use cases relying on the legacy refresh diff provider, the `PULUMI_USE_LEGACY_REFRESH_DIFF` environment variable can be set, which will disable desired-state diff computation. We only need to perform checks in `RefreshStep.{ResultOp,Apply}`, since downstream code will work correctly based on the presence or absence of a `DetailedDiff` in the step. ### Notes - https://github.com/pulumi/pulumi/issues/16144 affects some of these cases - though its technically orthogonal - https://github.com/pulumi/pulumi/issues/11279 is another technically orthogonal issue that many providers (at least TFBridge ones) - do not report back changes to input properties on Read when the input property (or property path) was missing on the inputs. This is again technically orthogonal - but leads to cases that appear "wrong" in terms of what is stored back into the state still - though the same as before this change. - Azure Native doesn't seem to handle `ignoreChanges` passed to Diff, so the ability to ignore changes on refresh doesn't currently work for Azure Native. ### Fixes * Fixes #16072 * Fixes #16278 * Fixes #16334 * Not quite #12346, but likely replaces the need for that Co-authored-by: Will Jones <will@sacharissa.co.uk>
2024-06-12 16:17:05 +00:00
func TestRefreshStepPatterns(t *testing.T) {
t.Parallel()
tests := []struct {
name string
inputs resource.PropertyMap
outputs resource.PropertyMap
readInputs resource.PropertyMap
readOutputs resource.PropertyMap
diffResult plugin.DiffResult
expectedDetailedDiff map[string]plugin.PropertyDiff
ignoreChanges []string
}{
{
name: "tfbridge 'computed' property changed",
inputs: resource.PropertyMap{},
outputs: resource.PropertyMap{
"etag": resource.NewStringProperty("abc"),
},
readInputs: resource.PropertyMap{},
readOutputs: resource.PropertyMap{
"etag": resource.NewStringProperty("def"),
},
diffResult: plugin.DiffResult{
// Diff newInputs, newOutputs, oldInputs
Changes: plugin.DiffNone,
DetailedDiff: map[string]plugin.PropertyDiff{},
},
expectedDetailedDiff: map[string]plugin.PropertyDiff{},
},
{
// Note: this is probably a case where the TF provider has a bug, a pure in property
// really shouldn't change, but this is common in TF providers.
name: "tfbridge 'required' property changed",
inputs: resource.PropertyMap{
"title": resource.NewStringProperty("test"),
},
outputs: resource.PropertyMap{
"title": resource.NewStringProperty("test"),
},
readInputs: resource.PropertyMap{
"title": resource.NewStringProperty("testtesttest"),
},
readOutputs: resource.PropertyMap{
"title": resource.NewStringProperty("testtesttest"),
},
diffResult: plugin.DiffResult{
// Diff newInputs, newOutputs, oldInputs
Changes: plugin.DiffSome,
DetailedDiff: map[string]plugin.PropertyDiff{
"title": {Kind: plugin.DiffUpdate},
},
},
expectedDetailedDiff: map[string]plugin.PropertyDiff{
"title": {Kind: plugin.DiffUpdate},
},
},
{
// Note: this is probably a case where the TF provider has a bug, a pure in property
// really shouldn't change, but this is common in TF providers.
name: "tfbridge 'required' property changed w/ ignoreChanges",
ignoreChanges: []string{"title"},
inputs: resource.PropertyMap{
"title": resource.NewStringProperty("test"),
},
outputs: resource.PropertyMap{
"title": resource.NewStringProperty("test"),
},
readInputs: resource.PropertyMap{
"title": resource.NewStringProperty("testtesttest"),
},
readOutputs: resource.PropertyMap{
"title": resource.NewStringProperty("testtesttest"),
},
diffResult: plugin.DiffResult{
// Diff newInputs, newOutputs, oldInputs
Changes: plugin.DiffNone,
DetailedDiff: map[string]plugin.PropertyDiff{},
},
expectedDetailedDiff: map[string]plugin.PropertyDiff{},
},
{
// Note: this is probably a case where the TF provider has a bug, a pure in property
// really shouldn't change, but this is common in TF providers.
name: "tfbridge 'optional' property changed",
inputs: resource.PropertyMap{},
outputs: resource.PropertyMap{
"body": resource.NewStringProperty(""),
},
readInputs: resource.PropertyMap{
// Pretty sure its a bug in tfbridge that it doesn't populate the new value
// into inputs for an `optional` property. But that's what it does so
// testing against the current behaviour.
},
readOutputs: resource.PropertyMap{
"body": resource.NewStringProperty("bodybodybody"),
},
diffResult: plugin.DiffResult{
// Diff newInputs, newOutputs, oldInputs
Changes: plugin.DiffSome,
DetailedDiff: map[string]plugin.PropertyDiff{
"body": {Kind: plugin.DiffDelete},
},
},
expectedDetailedDiff: map[string]plugin.PropertyDiff{
"body": {Kind: plugin.DiffAdd},
},
},
{
// Note: this is probably a case where the TF provider has a bug, a pure in property
// really shouldn't change, but this is common in TF providers.
name: "tfbridge 'optional' property changed w/ ignoreChanges",
ignoreChanges: []string{"body"},
inputs: resource.PropertyMap{},
outputs: resource.PropertyMap{
"body": resource.NewStringProperty(""),
},
readInputs: resource.PropertyMap{
// Pretty sure its a bug in tfbridge that it doesn't populate the new value
// into inputs for an `optional` property. But that's what it does so
// testing against the current behaviour.
},
readOutputs: resource.PropertyMap{
"body": resource.NewStringProperty("bodybodybody"),
},
diffResult: plugin.DiffResult{
// Diff newInputs, newOutputs, oldInputs
Changes: plugin.DiffNone,
DetailedDiff: map[string]plugin.PropertyDiff{},
},
expectedDetailedDiff: map[string]plugin.PropertyDiff{},
},
{
name: "tfbridge 'optional+computed' property element added",
inputs: resource.PropertyMap{},
outputs: resource.PropertyMap{
"tags": resource.NewObjectProperty(resource.PropertyMap{}),
},
readInputs: resource.PropertyMap{},
readOutputs: resource.PropertyMap{
"tags": resource.NewObjectProperty((resource.PropertyMap{
"foo": resource.NewStringProperty("bar"),
})),
},
diffResult: plugin.DiffResult{
// Diff newInputs, newOutputs, oldInputs
Changes: plugin.DiffSome,
DetailedDiff: map[string]plugin.PropertyDiff{
"tags": {Kind: plugin.DiffUpdate},
"tags.foo": {Kind: plugin.DiffDelete},
},
},
expectedDetailedDiff: map[string]plugin.PropertyDiff{
"tags": {Kind: plugin.DiffUpdate},
"tags.foo": {Kind: plugin.DiffAdd},
},
},
{
name: "tfbridge 'optional+computed' property element changed",
inputs: resource.PropertyMap{
"tags": resource.NewObjectProperty(resource.PropertyMap{
"foo": resource.NewStringProperty("bar"),
}),
},
outputs: resource.PropertyMap{
"tags": resource.NewObjectProperty(resource.PropertyMap{
"foo": resource.NewStringProperty("bar"),
}),
},
readInputs: resource.PropertyMap{
"tags": resource.NewObjectProperty((resource.PropertyMap{
"foo": resource.NewStringProperty("baz"),
})),
},
readOutputs: resource.PropertyMap{
"tags": resource.NewObjectProperty((resource.PropertyMap{
"foo": resource.NewStringProperty("baz"),
})),
},
diffResult: plugin.DiffResult{
// Diff newInputs, newOutputs, oldInputs
Changes: plugin.DiffSome,
DetailedDiff: map[string]plugin.PropertyDiff{
"tags.foo": {Kind: plugin.DiffUpdate},
},
},
expectedDetailedDiff: map[string]plugin.PropertyDiff{
"tags.foo": {Kind: plugin.DiffUpdate},
},
},
}
for _, tc := range tests {
s := &RefreshStep{
old: &resource.State{
URN: "some-urn",
ID: "some-id",
Type: "some-type",
Custom: true,
Provider: "urn:pulumi:stack::project::pulumi:providers:aws::default_5_42_0::denydefaultprovider",
Inputs: tc.inputs,
Outputs: tc.outputs,
},
deployment: &Deployment{
opts: &Options{
DryRun: true,
},
Change `pulumi refresh` to report diff relative to desired state instead of relative to only output changes (#16146) Presently, the behaviour of diffing during refresh steps is incomplete, returning only an "output diff" that presents the changes in outputs. This commit changes refresh steps so that: * they compute a diff similar to the one that would be computed if a `preview` were run immediately after the refresh, which is more typically what users expect and want; and * `IgnoreChanges` resource options are respected when performing the new desired-state diffs, so that property additions or changes reported by a refresh can be ignored. In particular, `IgnoreChanges` can now be used to acknowledge that part or all of a resource may change in the provider, but the user is OK with this and doesn't want to be notified about it during a refresh. Importantly, this means that the diff won't be reported, but also that the changes won't be applied to state. The implementation covers the following: * A diff is computed using the inputs from the program and then inverting the result, since in the case of a refresh the diff is being driven by the provider side and not the program. This doesn't change what is stored back into the state, but it does produce a diff that is more aligned with the "true changes to the desired state". * `IgnoreChanges` resource options are now stored in state, so that this information can be used in refresh operations that do not have access to/run the program. * In the context of a refresh operation, `IgnoreChanges` applies to *both* input and output properties. This differs from the behaviour of a normal update operation, where `IgnoreChanges` only considers input properties. * The special `"*"` value for `IgnoreChanges` can be used to ignore all properties. It _also_ ignores the case where the resource cannot be found in the provider, and instead keeps the resource intact in state with its existing input and output properties. Because the program is not run for refresh operations, `IgnoreChanges` options must be applied separately before a refresh takes place. This can be accomplished using e.g. a `pulumi up` that applies the options prior to a refresh. We should investigate perhaps providing a `pulumi state set ...`-like CLI to make these sorts of changes directly to a state. For use cases relying on the legacy refresh diff provider, the `PULUMI_USE_LEGACY_REFRESH_DIFF` environment variable can be set, which will disable desired-state diff computation. We only need to perform checks in `RefreshStep.{ResultOp,Apply}`, since downstream code will work correctly based on the presence or absence of a `DetailedDiff` in the step. ### Notes - https://github.com/pulumi/pulumi/issues/16144 affects some of these cases - though its technically orthogonal - https://github.com/pulumi/pulumi/issues/11279 is another technically orthogonal issue that many providers (at least TFBridge ones) - do not report back changes to input properties on Read when the input property (or property path) was missing on the inputs. This is again technically orthogonal - but leads to cases that appear "wrong" in terms of what is stored back into the state still - though the same as before this change. - Azure Native doesn't seem to handle `ignoreChanges` passed to Diff, so the ability to ignore changes on refresh doesn't currently work for Azure Native. ### Fixes * Fixes #16072 * Fixes #16278 * Fixes #16334 * Not quite #12346, but likely replaces the need for that Co-authored-by: Will Jones <will@sacharissa.co.uk>
2024-06-12 16:17:05 +00:00
},
provider: &deploytest.Provider{
ReadF: func(_ context.Context, req plugin.ReadRequest) (plugin.ReadResponse, error) {
return plugin.ReadResponse{
ReadResult: plugin.ReadResult{
ID: req.ID,
Inputs: tc.readInputs,
Outputs: tc.readOutputs,
},
Status: resource.StatusOK,
}, nil
Change `pulumi refresh` to report diff relative to desired state instead of relative to only output changes (#16146) Presently, the behaviour of diffing during refresh steps is incomplete, returning only an "output diff" that presents the changes in outputs. This commit changes refresh steps so that: * they compute a diff similar to the one that would be computed if a `preview` were run immediately after the refresh, which is more typically what users expect and want; and * `IgnoreChanges` resource options are respected when performing the new desired-state diffs, so that property additions or changes reported by a refresh can be ignored. In particular, `IgnoreChanges` can now be used to acknowledge that part or all of a resource may change in the provider, but the user is OK with this and doesn't want to be notified about it during a refresh. Importantly, this means that the diff won't be reported, but also that the changes won't be applied to state. The implementation covers the following: * A diff is computed using the inputs from the program and then inverting the result, since in the case of a refresh the diff is being driven by the provider side and not the program. This doesn't change what is stored back into the state, but it does produce a diff that is more aligned with the "true changes to the desired state". * `IgnoreChanges` resource options are now stored in state, so that this information can be used in refresh operations that do not have access to/run the program. * In the context of a refresh operation, `IgnoreChanges` applies to *both* input and output properties. This differs from the behaviour of a normal update operation, where `IgnoreChanges` only considers input properties. * The special `"*"` value for `IgnoreChanges` can be used to ignore all properties. It _also_ ignores the case where the resource cannot be found in the provider, and instead keeps the resource intact in state with its existing input and output properties. Because the program is not run for refresh operations, `IgnoreChanges` options must be applied separately before a refresh takes place. This can be accomplished using e.g. a `pulumi up` that applies the options prior to a refresh. We should investigate perhaps providing a `pulumi state set ...`-like CLI to make these sorts of changes directly to a state. For use cases relying on the legacy refresh diff provider, the `PULUMI_USE_LEGACY_REFRESH_DIFF` environment variable can be set, which will disable desired-state diff computation. We only need to perform checks in `RefreshStep.{ResultOp,Apply}`, since downstream code will work correctly based on the presence or absence of a `DetailedDiff` in the step. ### Notes - https://github.com/pulumi/pulumi/issues/16144 affects some of these cases - though its technically orthogonal - https://github.com/pulumi/pulumi/issues/11279 is another technically orthogonal issue that many providers (at least TFBridge ones) - do not report back changes to input properties on Read when the input property (or property path) was missing on the inputs. This is again technically orthogonal - but leads to cases that appear "wrong" in terms of what is stored back into the state still - though the same as before this change. - Azure Native doesn't seem to handle `ignoreChanges` passed to Diff, so the ability to ignore changes on refresh doesn't currently work for Azure Native. ### Fixes * Fixes #16072 * Fixes #16278 * Fixes #16334 * Not quite #12346, but likely replaces the need for that Co-authored-by: Will Jones <will@sacharissa.co.uk>
2024-06-12 16:17:05 +00:00
},
DiffF: func(context.Context, plugin.DiffRequest) (plugin.DiffResponse, error) {
Change `pulumi refresh` to report diff relative to desired state instead of relative to only output changes (#16146) Presently, the behaviour of diffing during refresh steps is incomplete, returning only an "output diff" that presents the changes in outputs. This commit changes refresh steps so that: * they compute a diff similar to the one that would be computed if a `preview` were run immediately after the refresh, which is more typically what users expect and want; and * `IgnoreChanges` resource options are respected when performing the new desired-state diffs, so that property additions or changes reported by a refresh can be ignored. In particular, `IgnoreChanges` can now be used to acknowledge that part or all of a resource may change in the provider, but the user is OK with this and doesn't want to be notified about it during a refresh. Importantly, this means that the diff won't be reported, but also that the changes won't be applied to state. The implementation covers the following: * A diff is computed using the inputs from the program and then inverting the result, since in the case of a refresh the diff is being driven by the provider side and not the program. This doesn't change what is stored back into the state, but it does produce a diff that is more aligned with the "true changes to the desired state". * `IgnoreChanges` resource options are now stored in state, so that this information can be used in refresh operations that do not have access to/run the program. * In the context of a refresh operation, `IgnoreChanges` applies to *both* input and output properties. This differs from the behaviour of a normal update operation, where `IgnoreChanges` only considers input properties. * The special `"*"` value for `IgnoreChanges` can be used to ignore all properties. It _also_ ignores the case where the resource cannot be found in the provider, and instead keeps the resource intact in state with its existing input and output properties. Because the program is not run for refresh operations, `IgnoreChanges` options must be applied separately before a refresh takes place. This can be accomplished using e.g. a `pulumi up` that applies the options prior to a refresh. We should investigate perhaps providing a `pulumi state set ...`-like CLI to make these sorts of changes directly to a state. For use cases relying on the legacy refresh diff provider, the `PULUMI_USE_LEGACY_REFRESH_DIFF` environment variable can be set, which will disable desired-state diff computation. We only need to perform checks in `RefreshStep.{ResultOp,Apply}`, since downstream code will work correctly based on the presence or absence of a `DetailedDiff` in the step. ### Notes - https://github.com/pulumi/pulumi/issues/16144 affects some of these cases - though its technically orthogonal - https://github.com/pulumi/pulumi/issues/11279 is another technically orthogonal issue that many providers (at least TFBridge ones) - do not report back changes to input properties on Read when the input property (or property path) was missing on the inputs. This is again technically orthogonal - but leads to cases that appear "wrong" in terms of what is stored back into the state still - though the same as before this change. - Azure Native doesn't seem to handle `ignoreChanges` passed to Diff, so the ability to ignore changes on refresh doesn't currently work for Azure Native. ### Fixes * Fixes #16072 * Fixes #16278 * Fixes #16334 * Not quite #12346, but likely replaces the need for that Co-authored-by: Will Jones <will@sacharissa.co.uk>
2024-06-12 16:17:05 +00:00
return tc.diffResult, nil
},
},
}
status, _, err := s.Apply()
Change `pulumi refresh` to report diff relative to desired state instead of relative to only output changes (#16146) Presently, the behaviour of diffing during refresh steps is incomplete, returning only an "output diff" that presents the changes in outputs. This commit changes refresh steps so that: * they compute a diff similar to the one that would be computed if a `preview` were run immediately after the refresh, which is more typically what users expect and want; and * `IgnoreChanges` resource options are respected when performing the new desired-state diffs, so that property additions or changes reported by a refresh can be ignored. In particular, `IgnoreChanges` can now be used to acknowledge that part or all of a resource may change in the provider, but the user is OK with this and doesn't want to be notified about it during a refresh. Importantly, this means that the diff won't be reported, but also that the changes won't be applied to state. The implementation covers the following: * A diff is computed using the inputs from the program and then inverting the result, since in the case of a refresh the diff is being driven by the provider side and not the program. This doesn't change what is stored back into the state, but it does produce a diff that is more aligned with the "true changes to the desired state". * `IgnoreChanges` resource options are now stored in state, so that this information can be used in refresh operations that do not have access to/run the program. * In the context of a refresh operation, `IgnoreChanges` applies to *both* input and output properties. This differs from the behaviour of a normal update operation, where `IgnoreChanges` only considers input properties. * The special `"*"` value for `IgnoreChanges` can be used to ignore all properties. It _also_ ignores the case where the resource cannot be found in the provider, and instead keeps the resource intact in state with its existing input and output properties. Because the program is not run for refresh operations, `IgnoreChanges` options must be applied separately before a refresh takes place. This can be accomplished using e.g. a `pulumi up` that applies the options prior to a refresh. We should investigate perhaps providing a `pulumi state set ...`-like CLI to make these sorts of changes directly to a state. For use cases relying on the legacy refresh diff provider, the `PULUMI_USE_LEGACY_REFRESH_DIFF` environment variable can be set, which will disable desired-state diff computation. We only need to perform checks in `RefreshStep.{ResultOp,Apply}`, since downstream code will work correctly based on the presence or absence of a `DetailedDiff` in the step. ### Notes - https://github.com/pulumi/pulumi/issues/16144 affects some of these cases - though its technically orthogonal - https://github.com/pulumi/pulumi/issues/11279 is another technically orthogonal issue that many providers (at least TFBridge ones) - do not report back changes to input properties on Read when the input property (or property path) was missing on the inputs. This is again technically orthogonal - but leads to cases that appear "wrong" in terms of what is stored back into the state still - though the same as before this change. - Azure Native doesn't seem to handle `ignoreChanges` passed to Diff, so the ability to ignore changes on refresh doesn't currently work for Azure Native. ### Fixes * Fixes #16072 * Fixes #16278 * Fixes #16334 * Not quite #12346, but likely replaces the need for that Co-authored-by: Will Jones <will@sacharissa.co.uk>
2024-06-12 16:17:05 +00:00
assert.Equal(t, s.diff.DetailedDiff, tc.expectedDetailedDiff)
assert.NoError(t, err)
assert.Equal(t, resource.StatusOK, status)
}
}
func TestRefreshStep(t *testing.T) {
t.Parallel()
t.Run("Apply", func(t *testing.T) {
t.Parallel()
t.Run("error getting provider", func(t *testing.T) {
t.Parallel()
s := &RefreshStep{
deployment: &Deployment{
opts: &Options{
DryRun: true,
},
},
old: &resource.State{
Custom: true,
// Use denydefaultprovider ID to ensure failure.
Provider: "urn:pulumi:stack::project::pulumi:providers:aws::default_5_42_0::denydefaultprovider",
},
}
status, _, err := s.Apply()
assert.ErrorContains(t, err, "Default provider for 'default_5_42_0' disabled.")
assert.Equal(t, resource.StatusOK, status)
})
t.Run("failure in provider", func(t *testing.T) {
t.Parallel()
expectedErr := errors.New("expected error")
s := &RefreshStep{
old: &resource.State{
URN: "some-urn",
ID: "some-id",
Custom: true,
// Use denydefaultprovider ID to ensure failure.
Provider: "urn:pulumi:stack::project::pulumi:providers:aws::default_5_42_0::denydefaultprovider",
},
deployment: &Deployment{
opts: &Options{
DryRun: true,
},
},
provider: &deploytest.Provider{
ReadF: func(context.Context, plugin.ReadRequest) (plugin.ReadResponse, error) {
return plugin.ReadResponse{}, expectedErr
},
},
}
status, _, err := s.Apply()
assert.ErrorIs(t, err, expectedErr)
assert.Equal(t, resource.StatusOK, status)
})
t.Run("partial failure in provider", func(t *testing.T) {
t.Parallel()
s := &RefreshStep{
old: &resource.State{
URN: "some-urn",
ID: "some-id",
Type: "some-type",
Custom: true,
// Use denydefaultprovider ID to ensure failure.
Provider: "urn:pulumi:stack::project::pulumi:providers:aws::default_5_42_0::denydefaultprovider",
},
deployment: &Deployment{
ctx: &plugin.Context{Diag: &deploytest.NoopSink{}},
opts: &Options{
DryRun: true,
},
},
provider: &deploytest.Provider{
ReadF: func(context.Context, plugin.ReadRequest) (plugin.ReadResponse, error) {
return plugin.ReadResponse{
ReadResult: plugin.ReadResult{
ID: "new-id",
Inputs: resource.PropertyMap{
"inputs-key": resource.NewStringProperty("expected-value"),
},
Outputs: resource.PropertyMap{
"outputs-key": resource.NewStringProperty("expected-value"),
},
},
Status: resource.StatusPartialFailure,
}, &plugin.InitError{
Reasons: []string{
"intentional error",
},
}
},
},
}
status, _, err := s.Apply()
assert.NoError(t, err, "InitError should be discarded")
assert.Equal(t, resource.StatusPartialFailure, status)
// News should be updated.
assert.Len(t, s.new.InitErrors, 1)
assert.Equal(t, resource.PropertyMap{
"outputs-key": resource.NewStringProperty("expected-value"),
}, s.new.Outputs)
assert.Equal(t, resource.ID("new-id"), s.new.ID)
})
})
}
func TestImportStep(t *testing.T) {
t.Parallel()
t.Run("Apply", func(t *testing.T) {
t.Parallel()
t.Run("missing parent", func(t *testing.T) {
t.Parallel()
s := &ImportStep{
planned: true,
new: &resource.State{
Parent: "urn:pulumi:stack::project::foo:bar:Bar::name",
},
deployment: &Deployment{
opts: &Options{
DryRun: true,
},
olds: map[resource.URN]*resource.State{},
news: &gsync.Map[urn.URN, *resource.State]{},
},
}
status, _, err := s.Apply()
assert.ErrorContains(t, err, "unknown parent")
assert.Equal(t, resource.StatusOK, status)
})
t.Run("getProvider error", func(t *testing.T) {
t.Parallel()
s := &ImportStep{
deployment: &Deployment{
opts: &Options{
DryRun: true,
},
olds: map[resource.URN]*resource.State{},
news: &gsync.Map[urn.URN, *resource.State]{},
},
new: &resource.State{
URN: "urn:pulumi:stack::project::foo:bar:Bar::name",
ID: "some-id",
Custom: true,
},
}
status, _, err := s.Apply()
assert.ErrorContains(t, err, "bad provider reference")
assert.Equal(t, resource.StatusOK, status)
})
t.Run("provider read error", func(t *testing.T) {
t.Parallel()
t.Run("error", func(t *testing.T) {
t.Parallel()
expectedErr := errors.New("expected error")
s := &ImportStep{
deployment: &Deployment{
opts: &Options{
DryRun: true,
},
olds: map[resource.URN]*resource.State{},
news: &gsync.Map[urn.URN, *resource.State]{},
},
new: &resource.State{
URN: "urn:pulumi:stack::project::foo:bar:Bar::name",
ID: "some-id",
Custom: true,
},
provider: &deploytest.Provider{
ReadF: func(context.Context, plugin.ReadRequest) (plugin.ReadResponse, error) {
return plugin.ReadResponse{}, expectedErr
},
},
}
status, _, err := s.Apply()
assert.ErrorIs(t, err, expectedErr)
assert.Equal(t, resource.StatusOK, status)
})
t.Run("init error", func(t *testing.T) {
t.Parallel()
s := &ImportStep{
deployment: &Deployment{
opts: &Options{
DryRun: true,
},
olds: map[resource.URN]*resource.State{},
news: &gsync.Map[urn.URN, *resource.State]{},
},
new: &resource.State{
URN: "urn:pulumi:stack::project::foo:bar:Bar::name",
ID: "some-id",
Custom: true,
},
provider: &deploytest.Provider{
ReadF: func(context.Context, plugin.ReadRequest) (plugin.ReadResponse, error) {
return plugin.ReadResponse{}, &plugin.InitError{
Reasons: []string{
"intentional error",
},
}
},
},
}
status, _, err := s.Apply()
assert.Error(t, err)
assert.Equal(t, resource.StatusOK, status)
assert.Len(t, s.new.InitErrors, 1)
})
t.Run("resource does not exist", func(t *testing.T) {
t.Parallel()
s := &ImportStep{
deployment: &Deployment{
opts: &Options{
DryRun: true,
},
olds: map[resource.URN]*resource.State{},
news: &gsync.Map[urn.URN, *resource.State]{},
},
new: &resource.State{
URN: "urn:pulumi:stack::project::foo:bar:Bar::name",
ID: "some-id",
Custom: true,
},
provider: &deploytest.Provider{
ReadF: func(context.Context, plugin.ReadRequest) (plugin.ReadResponse, error) {
return plugin.ReadResponse{}, nil
},
},
}
status, _, err := s.Apply()
assert.ErrorContains(t, err, "does not exist")
assert.Equal(t, resource.StatusOK, status)
})
t.Run("provider does not support importing resources", func(t *testing.T) {
t.Parallel()
s := &ImportStep{
deployment: &Deployment{
opts: &Options{
DryRun: true,
},
olds: map[resource.URN]*resource.State{},
news: &gsync.Map[urn.URN, *resource.State]{},
},
new: &resource.State{
URN: "urn:pulumi:stack::project::foo:bar:Bar::name",
ID: "some-id",
Custom: true,
},
provider: &deploytest.Provider{
ReadF: func(context.Context, plugin.ReadRequest) (plugin.ReadResponse, error) {
return plugin.ReadResponse{
ReadResult: plugin.ReadResult{
Outputs: resource.PropertyMap{},
},
Status: resource.StatusOK,
}, nil
},
},
}
status, _, err := s.Apply()
assert.ErrorContains(t, err, "provider does not support importing resources")
assert.Equal(t, resource.StatusOK, status)
})
})
t.Run("provider check error", func(t *testing.T) {
t.Parallel()
t.Run("error", func(t *testing.T) {
t.Parallel()
expectedErr := errors.New("expected error")
var readCalled bool
var checkCalled bool
s := &ImportStep{
deployment: &Deployment{
opts: &Options{
DryRun: true,
},
olds: map[resource.URN]*resource.State{},
news: &gsync.Map[urn.URN, *resource.State]{},
},
new: &resource.State{
URN: "urn:pulumi:stack::project::foo:bar:Bar::name",
ID: "some-id",
Type: "foo:bar:Bar",
Custom: true,
},
randomSeed: []byte{},
provider: &deploytest.Provider{
ReadF: func(context.Context, plugin.ReadRequest) (plugin.ReadResponse, error) {
readCalled = true
return plugin.ReadResponse{
ReadResult: plugin.ReadResult{
Outputs: resource.PropertyMap{},
Inputs: resource.PropertyMap{},
},
Status: resource.StatusOK,
}, nil
},
CheckF: func(context.Context, plugin.CheckRequest) (plugin.CheckResponse, error) {
checkCalled = true
return plugin.CheckResponse{}, expectedErr
},
},
}
_, _, err := s.Apply()
assert.ErrorIs(t, err, expectedErr)
assert.True(t, readCalled)
assert.True(t, checkCalled)
})
t.Run("failures", func(t *testing.T) {
t.Parallel()
var readCalled bool
var checkCalled bool
s := &ImportStep{
deployment: &Deployment{
ctx: &plugin.Context{
Diag: &deploytest.NoopSink{},
},
opts: &Options{
DryRun: true,
},
olds: map[resource.URN]*resource.State{},
news: &gsync.Map[urn.URN, *resource.State]{},
},
new: &resource.State{
URN: "urn:pulumi:stack::project::foo:bar:Bar::name",
ID: "some-id",
Type: "foo:bar:Bar",
Custom: true,
Parent: "urn:pulumi:stack::project::pulumi:pulumi:Stack::name",
Provider: "urn:pulumi:stack::project::pulumi:providers:provider::name::uuid",
},
planned: true,
randomSeed: []byte{},
provider: &deploytest.Provider{
ReadF: func(context.Context, plugin.ReadRequest) (plugin.ReadResponse, error) {
readCalled = true
return plugin.ReadResponse{
ReadResult: plugin.ReadResult{
Outputs: resource.PropertyMap{},
Inputs: resource.PropertyMap{},
},
Status: resource.StatusOK,
}, nil
},
CheckF: func(context.Context, plugin.CheckRequest) (plugin.CheckResponse, error) {
checkCalled = true
return plugin.CheckResponse{
Properties: resource.PropertyMap{},
Failures: []plugin.CheckFailure{
{
Reason: "intentional failure",
},
},
}, nil
},
},
}
_, _, err := s.Apply()
assert.NoError(t, err)
assert.True(t, readCalled)
assert.True(t, checkCalled)
})
})
})
}
func TestGetProvider(t *testing.T) {
t.Parallel()
t.Run("ensure default is not selected", func(t *testing.T) {
t.Parallel()
s := &CreateStep{
new: &resource.State{
Provider: "invalid-provider",
},
}
prov, err := getProvider(s, s.provider)
assert.Nil(t, prov)
assert.ErrorContains(t, err, "bad provider reference")
})
t.Run("ensure default is not selected", func(t *testing.T) {
t.Parallel()
expectedProvider := &deploytest.Provider{}
s := &CreateStep{
provider: expectedProvider,
new: &resource.State{
Provider: "invalid-provider",
},
}
prov, err := getProvider(s, s.provider)
assert.NoError(t, err)
assert.Equal(t, expectedProvider, prov)
})
}
func TestSuffix(t *testing.T) {
t.Parallel()
for op, expectation := range map[display.StepOp]string{
OpSame: "",
OpCreate: "",
OpDelete: "",
OpDeleteReplaced: "",
OpRead: "",
OpReadDiscard: "",
OpDiscardReplaced: "",
OpRemovePendingReplace: "",
OpImport: "",
"not-a-real-step-op": "",
OpCreateReplacement: colors.Reset,
OpUpdate: colors.Reset,
OpReplace: colors.Reset,
OpReadReplacement: colors.Reset,
OpRefresh: colors.Reset,
OpImportReplacement: colors.Reset,
} {
assert.Equal(t, expectation, Suffix(op))
}
}