pulumi/pkg/backend/display/progress_test.go

284 lines
7.9 KiB
Go
Raw Permalink 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 display
// Note: to regenerate the baselines for these tests, run `go test` with `PULUMI_ACCEPT=true`.
import (
"bytes"
"fmt"
"os"
"path/filepath"
"testing"
"github.com/pulumi/pulumi/pkg/v3/backend/display/internal/terminal"
"github.com/pulumi/pulumi/pkg/v3/display"
"github.com/pulumi/pulumi/pkg/v3/engine"
"github.com/pulumi/pulumi/pkg/v3/resource/deploy"
"github.com/pulumi/pulumi/sdk/v3/go/common/diag"
"github.com/pulumi/pulumi/sdk/v3/go/common/diag/colors"
"github.com/pulumi/pulumi/sdk/v3/go/common/resource"
Add tokens.StackName (#14487) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This adds a new type `tokens.StackName` which is a relatively strongly typed container for a stack name. The only weakly typed aspect of it is Go will always allow the "zero" value to be created for a struct, which for a stack name is the empty string which is invalid. To prevent introducing unexpected empty strings when working with stack names the `String()` method will panic for zero initialized stack names. Apart from the zero value, all other instances of `StackName` are via `ParseStackName` which returns a descriptive error if the string is not valid. This PR only updates "pkg/" to use this type. There are a number of places in "sdk/" which could do with this type as well, but there's no harm in doing a staggered roll out, and some parts of "sdk/" are user facing and will probably have to stay on the current `tokens.Name` and `tokens.QName` types. There are two places in the system where we panic on invalid stack names, both in the http backend. This _should_ be fine as we've had long standing validation that stacks created in the service are valid stack names. Just in case people have managed to introduce invalid stack names, there is the `PULUMI_DISABLE_VALIDATION` environment variable which will turn off the validation _and_ panicing for stack names. Users can use that to temporarily disable the validation and continue working, but it should only be seen as a temporary measure. If they have invalid names they should rename them, or if they think they should be valid raise an issue with us to change the validation code. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2023-11-15 07:44:54 +00:00
"github.com/pulumi/pulumi/sdk/v3/go/common/tokens"
"github.com/pulumi/pulumi/sdk/v3/go/common/util/cmdutil"
"github.com/stretchr/testify/assert"
"github.com/stretchr/testify/require"
)
func testProgressEvents(t *testing.T, path string, accept, interactive bool, width, height int, raw bool) {
events, err := loadEvents(path)
require.NoError(t, err)
suffix := ".non-interactive"
if interactive {
suffix = fmt.Sprintf(".interactive-%vx%v", width, height)
if !raw {
suffix += "-cooked"
}
}
var expectedStdout []byte
var expectedStderr []byte
if !accept {
expectedStdout, err = os.ReadFile(path + suffix + ".stdout.txt")
require.NoError(t, err)
expectedStderr, err = os.ReadFile(path + suffix + ".stderr.txt")
require.NoError(t, err)
}
eventChannel, doneChannel := make(chan engine.Event), make(chan bool)
var stdout bytes.Buffer
var stderr bytes.Buffer
Add tokens.StackName (#14487) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This adds a new type `tokens.StackName` which is a relatively strongly typed container for a stack name. The only weakly typed aspect of it is Go will always allow the "zero" value to be created for a struct, which for a stack name is the empty string which is invalid. To prevent introducing unexpected empty strings when working with stack names the `String()` method will panic for zero initialized stack names. Apart from the zero value, all other instances of `StackName` are via `ParseStackName` which returns a descriptive error if the string is not valid. This PR only updates "pkg/" to use this type. There are a number of places in "sdk/" which could do with this type as well, but there's no harm in doing a staggered roll out, and some parts of "sdk/" are user facing and will probably have to stay on the current `tokens.Name` and `tokens.QName` types. There are two places in the system where we panic on invalid stack names, both in the http backend. This _should_ be fine as we've had long standing validation that stacks created in the service are valid stack names. Just in case people have managed to introduce invalid stack names, there is the `PULUMI_DISABLE_VALIDATION` environment variable which will turn off the validation _and_ panicing for stack names. Users can use that to temporarily disable the validation and continue working, but it should only be seen as a temporary measure. If they have invalid names they should rename them, or if they think they should be valid raise an issue with us to change the validation code. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2023-11-15 07:44:54 +00:00
go ShowProgressEvents(
"test", "update", tokens.MustParseStackName("stack"), "project", "link", eventChannel, doneChannel,
Options{
IsInteractive: interactive,
Color: colors.Raw,
ShowConfig: true,
ShowReplacementSteps: true,
ShowSameResources: true,
ShowReads: true,
Stdout: &stdout,
Stderr: &stderr,
term: terminal.NewMockTerminal(&stdout, width, height, true),
Add display to the engine tests (#16050) We want to add more test coverage to the display code. The best way to do that is to add it to the engine tests, that already cover most of the pulumi functionality. It's probably not really possible to review all of the output, but at least it gives us a baseline, which we can work with. There's a couple of tests that are flaky for reasons I don't quite understand yet. I marked them as to skip and we can look at them later. I'd rather get in the baseline tests sooner, rather than spending a bunch of time looking at that. The output differences also seem very minor, so not super concerning. The biggest remaining issue is that this doesn't interact well with the Chdir we're doing in the engine. We could either pass the CWD through, or just try to get rid of that Chdir. So this should only be merged after https://github.com/pulumi/pulumi/pull/15607. I've tried to split this into a few commits, separating out adding the testdata, so it's hopefully a little easier to review, even though the PR is still quite large. One other thing to note is that we're comparing that the output has all the same lines, and not that it is exactly the same. Because of how the engine is implemented, there's a bunch of race conditions otherwise, that would make us have to skip a bunch of tests, just because e.g. resource A is sometimes deleted before resource B and sometimes it's the other way around. The biggest downside of that is that running with `PULUMI_ACCEPT` will produce a diff even when there are no changes. Hopefully we won't have to run that way too often though, so it might not be a huge issue? --------- Co-authored-by: Fraser Waters <fraser@pulumi.com>
2024-05-13 07:18:25 +00:00
DeterministicOutput: true,
Add tokens.StackName (#14487) <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> This adds a new type `tokens.StackName` which is a relatively strongly typed container for a stack name. The only weakly typed aspect of it is Go will always allow the "zero" value to be created for a struct, which for a stack name is the empty string which is invalid. To prevent introducing unexpected empty strings when working with stack names the `String()` method will panic for zero initialized stack names. Apart from the zero value, all other instances of `StackName` are via `ParseStackName` which returns a descriptive error if the string is not valid. This PR only updates "pkg/" to use this type. There are a number of places in "sdk/" which could do with this type as well, but there's no harm in doing a staggered roll out, and some parts of "sdk/" are user facing and will probably have to stay on the current `tokens.Name` and `tokens.QName` types. There are two places in the system where we panic on invalid stack names, both in the http backend. This _should_ be fine as we've had long standing validation that stacks created in the service are valid stack names. Just in case people have managed to introduce invalid stack names, there is the `PULUMI_DISABLE_VALIDATION` environment variable which will turn off the validation _and_ panicing for stack names. Users can use that to temporarily disable the validation and continue working, but it should only be seen as a temporary measure. If they have invalid names they should rename them, or if they think they should be valid raise an issue with us to change the validation code. ## Checklist - [x] I have run `make tidy` to update any new dependencies - [x] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2023-11-15 07:44:54 +00:00
}, false)
for _, e := range events {
eventChannel <- e
}
<-doneChannel
if !accept {
assert.Equal(t, string(expectedStdout), stdout.String())
assert.Equal(t, string(expectedStderr), stderr.String())
} else {
all: Reformat with gofumpt Per team discussion, switching to gofumpt. [gofumpt][1] is an alternative, stricter alternative to gofmt. It addresses other stylistic concerns that gofmt doesn't yet cover. [1]: https://github.com/mvdan/gofumpt See the full list of [Added rules][2], but it includes: - Dropping empty lines around function bodies - Dropping unnecessary variable grouping when there's only one variable - Ensuring an empty line between multi-line functions - simplification (`-s` in gofmt) is always enabled - Ensuring multi-line function signatures end with `) {` on a separate line. [2]: https://github.com/mvdan/gofumpt#Added-rules gofumpt is stricter, but there's no lock-in. All gofumpt output is valid gofmt output, so if we decide we don't like it, it's easy to switch back without any code changes. gofumpt support is built into the tooling we use for development so this won't change development workflows. - golangci-lint includes a gofumpt check (enabled in this PR) - gopls, the LSP for Go, includes a gofumpt option (see [installation instrutions][3]) [3]: https://github.com/mvdan/gofumpt#installation This change was generated by running: ```bash gofumpt -w $(rg --files -g '*.go' | rg -v testdata | rg -v compilation_error) ``` The following files were manually tweaked afterwards: - pkg/cmd/pulumi/stack_change_secrets_provider.go: one of the lines overflowed and had comments in an inconvenient place - pkg/cmd/pulumi/destroy.go: `var x T = y` where `T` wasn't necessary - pkg/cmd/pulumi/policy_new.go: long line because of error message - pkg/backend/snapshot_test.go: long line trying to assign three variables in the same assignment I have included mention of gofumpt in the CONTRIBUTING.md.
2023-03-03 16:36:39 +00:00
err = os.WriteFile(path+suffix+".stdout.txt", stdout.Bytes(), 0o600)
require.NoError(t, err)
all: Reformat with gofumpt Per team discussion, switching to gofumpt. [gofumpt][1] is an alternative, stricter alternative to gofmt. It addresses other stylistic concerns that gofmt doesn't yet cover. [1]: https://github.com/mvdan/gofumpt See the full list of [Added rules][2], but it includes: - Dropping empty lines around function bodies - Dropping unnecessary variable grouping when there's only one variable - Ensuring an empty line between multi-line functions - simplification (`-s` in gofmt) is always enabled - Ensuring multi-line function signatures end with `) {` on a separate line. [2]: https://github.com/mvdan/gofumpt#Added-rules gofumpt is stricter, but there's no lock-in. All gofumpt output is valid gofmt output, so if we decide we don't like it, it's easy to switch back without any code changes. gofumpt support is built into the tooling we use for development so this won't change development workflows. - golangci-lint includes a gofumpt check (enabled in this PR) - gopls, the LSP for Go, includes a gofumpt option (see [installation instrutions][3]) [3]: https://github.com/mvdan/gofumpt#installation This change was generated by running: ```bash gofumpt -w $(rg --files -g '*.go' | rg -v testdata | rg -v compilation_error) ``` The following files were manually tweaked afterwards: - pkg/cmd/pulumi/stack_change_secrets_provider.go: one of the lines overflowed and had comments in an inconvenient place - pkg/cmd/pulumi/destroy.go: `var x T = y` where `T` wasn't necessary - pkg/cmd/pulumi/policy_new.go: long line because of error message - pkg/backend/snapshot_test.go: long line trying to assign three variables in the same assignment I have included mention of gofumpt in the CONTRIBUTING.md.
2023-03-03 16:36:39 +00:00
err = os.WriteFile(path+suffix+".stderr.txt", stderr.Bytes(), 0o600)
require.NoError(t, err)
}
}
func TestProgressEvents(t *testing.T) {
t.Parallel()
accept := cmdutil.IsTruthy(os.Getenv("PULUMI_ACCEPT"))
entries, err := os.ReadDir("testdata/not-truncated")
require.NoError(t, err)
dimensions := []struct{ width, height int }{
{width: 80, height: 24},
{width: 100, height: 80},
{width: 200, height: 80},
}
//nolint:paralleltest
for _, entry := range entries {
if entry.IsDir() || filepath.Ext(entry.Name()) != ".json" {
continue
}
path := filepath.Join("testdata/not-truncated", entry.Name())
t.Run(entry.Name()+"interactive", func(t *testing.T) {
t.Parallel()
for _, dim := range dimensions {
width, height := dim.width, dim.height
t.Run(fmt.Sprintf("%vx%v", width, height), func(t *testing.T) {
t.Parallel()
t.Run("raw", func(t *testing.T) {
testProgressEvents(t, path, accept, true, width, height, true)
})
t.Run("cooked", func(t *testing.T) {
testProgressEvents(t, path, accept, true, width, height, false)
})
})
}
})
t.Run(entry.Name()+"non-interactive", func(t *testing.T) {
t.Parallel()
testProgressEvents(t, path, accept, false, 80, 24, false)
})
}
}
// The following test checks that the status display elements have retain on delete details added.
func TestStatusDisplayFlags(t *testing.T) {
t.Parallel()
tests := []struct {
name string
stepOp display.StepOp
shouldRetain bool
}{
// Should display `retain`.
{"delete", deploy.OpDelete, true},
{"replace", deploy.OpReplace, true},
{"create-replacement", deploy.OpCreateReplacement, true},
{"delete-replaced", deploy.OpDeleteReplaced, true},
// Should be unaffected.
{"same", deploy.OpSame, false},
{"create", deploy.OpCreate, false},
{"update", deploy.OpUpdate, false},
{"read", deploy.OpRead, false},
{"read-replacement", deploy.OpReadReplacement, false},
{"refresh", deploy.OpRefresh, false},
{"discard", deploy.OpReadDiscard, false},
{"discard-replaced", deploy.OpDiscardReplaced, false},
{"import", deploy.OpImport, false},
{"import-replacement", deploy.OpImportReplacement, false},
// "remove-pending-replace" is not a valid step operation.
// {"remove-pending-replace", deploy.OpRemovePendingReplace, false},
}
for _, tt := range tests {
tt := tt
t.Run(tt.name, func(t *testing.T) {
t.Parallel()
d := &ProgressDisplay{}
name := resource.NewURN("test", "test", "test", "test", "test")
step := engine.StepEventMetadata{
URN: name,
Op: tt.stepOp,
Old: &engine.StepEventStateMetadata{
State: &resource.State{
RetainOnDelete: true,
},
},
}
doneStatus := d.getStepStatus(step,
true, // done
false, // failed
)
inProgressStatus := d.getStepStatus(step,
false, // done
false, // failed
)
if tt.shouldRetain {
assert.Contains(t, doneStatus, "[retain]", "%s should contain [retain] (done)", step.Op)
assert.Contains(t, inProgressStatus, "[retain]", "%s should contain [retain] (in-progress)", step.Op)
} else {
assert.NotContains(t, doneStatus, "[retain]", "%s should NOT contain [retain] (done)", step.Op)
assert.NotContains(t, inProgressStatus, "[retain]", "%s should NOT contain [retain] (in-progress)", step.Op)
}
})
}
}
func TestPrintDiagnosticsIsTolerantOfDiagnostics(t *testing.T) {
t.Parallel()
makeDisplayWithDiagnostic := func(sev diag.Severity) *ProgressDisplay {
return &ProgressDisplay{
eventUrnToResourceRow: map[resource.URN]ResourceRow{
"urn:pulumi:test::test::pulumi:pulumi:Stack::test": &resourceRowData{
diagInfo: &DiagInfo{
StreamIDToDiagPayloads: map[int32][]engine.DiagEventPayload{
0: {
{
Severity: sev,
},
},
},
},
},
},
}
}
tests := []struct {
name string
give diag.Severity
want bool
}{
{"info", diag.Info, false},
{"warning", diag.Warning, false},
{"error", diag.Error, true},
}
for _, tt := range tests {
tt := tt
t.Run(tt.name, func(t *testing.T) {
t.Parallel()
d := makeDisplayWithDiagnostic(tt.give)
got := d.printDiagnostics()
assert.Equal(t, tt.want, got, "printDiagnostics(%v) = %v, want %v", tt.give, got, tt.want)
})
}
}
add output for running policy packs (#14493) # Description :construction: This is a work in progress attempting to add some output for when policy packs are being loaded/compiled (which I realized was the actual reason for the slowdown, not that they were being run already). There's still some pretty obvious code quality issues as I've been throwing this together, and the URN's are not constructed properly yet either, so some of the output is less helpful than it could be. I'm mainly opening this to get some early feedback on whether this is the appropriate place to add the output, or if there are better alternatives. Also including a gif here of what this looks like. In particular the Name here needs to be improved, and the "Plan" might want to say "loading/compiling" or something similar instead? ![policy-pack](https://github.com/pulumi/pulumi/assets/191004/85cca146-d740-4e4c-96dc-cc26dca6bb90) Fixes #14453 ## Checklist - [ ] I have run `make tidy` to update any new dependencies - [ ] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [ ] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2023-11-15 11:19:31 +00:00
func TestProgressPolicyPacks(t *testing.T) {
t.Parallel()
eventChannel, doneChannel := make(chan engine.Event), make(chan bool)
var stdout bytes.Buffer
var stderr bytes.Buffer
go ShowProgressEvents(
"test", "update", tokens.MustParseStackName("stack"), "project", "link", eventChannel, doneChannel,
Options{
IsInteractive: true,
Color: colors.Raw,
ShowConfig: true,
ShowReplacementSteps: true,
ShowSameResources: true,
ShowReads: true,
Stdout: &stdout,
Stderr: &stderr,
term: terminal.NewMockTerminal(&stdout, 80, 24, true),
Add display to the engine tests (#16050) We want to add more test coverage to the display code. The best way to do that is to add it to the engine tests, that already cover most of the pulumi functionality. It's probably not really possible to review all of the output, but at least it gives us a baseline, which we can work with. There's a couple of tests that are flaky for reasons I don't quite understand yet. I marked them as to skip and we can look at them later. I'd rather get in the baseline tests sooner, rather than spending a bunch of time looking at that. The output differences also seem very minor, so not super concerning. The biggest remaining issue is that this doesn't interact well with the Chdir we're doing in the engine. We could either pass the CWD through, or just try to get rid of that Chdir. So this should only be merged after https://github.com/pulumi/pulumi/pull/15607. I've tried to split this into a few commits, separating out adding the testdata, so it's hopefully a little easier to review, even though the PR is still quite large. One other thing to note is that we're comparing that the output has all the same lines, and not that it is exactly the same. Because of how the engine is implemented, there's a bunch of race conditions otherwise, that would make us have to skip a bunch of tests, just because e.g. resource A is sometimes deleted before resource B and sometimes it's the other way around. The biggest downside of that is that running with `PULUMI_ACCEPT` will produce a diff even when there are no changes. Hopefully we won't have to run that way too often though, so it might not be a huge issue? --------- Co-authored-by: Fraser Waters <fraser@pulumi.com>
2024-05-13 07:18:25 +00:00
DeterministicOutput: true,
add output for running policy packs (#14493) # Description :construction: This is a work in progress attempting to add some output for when policy packs are being loaded/compiled (which I realized was the actual reason for the slowdown, not that they were being run already). There's still some pretty obvious code quality issues as I've been throwing this together, and the URN's are not constructed properly yet either, so some of the output is less helpful than it could be. I'm mainly opening this to get some early feedback on whether this is the appropriate place to add the output, or if there are better alternatives. Also including a gif here of what this looks like. In particular the Name here needs to be improved, and the "Plan" might want to say "loading/compiling" or something similar instead? ![policy-pack](https://github.com/pulumi/pulumi/assets/191004/85cca146-d740-4e4c-96dc-cc26dca6bb90) Fixes #14453 ## Checklist - [ ] I have run `make tidy` to update any new dependencies - [ ] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [ ] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2023-11-15 11:19:31 +00:00
}, false)
// Send policy pack event to the channel
eventChannel <- engine.NewEvent(engine.PolicyLoadEventPayload{})
add output for running policy packs (#14493) # Description :construction: This is a work in progress attempting to add some output for when policy packs are being loaded/compiled (which I realized was the actual reason for the slowdown, not that they were being run already). There's still some pretty obvious code quality issues as I've been throwing this together, and the URN's are not constructed properly yet either, so some of the output is less helpful than it could be. I'm mainly opening this to get some early feedback on whether this is the appropriate place to add the output, or if there are better alternatives. Also including a gif here of what this looks like. In particular the Name here needs to be improved, and the "Plan" might want to say "loading/compiling" or something similar instead? ![policy-pack](https://github.com/pulumi/pulumi/assets/191004/85cca146-d740-4e4c-96dc-cc26dca6bb90) Fixes #14453 ## Checklist - [ ] I have run `make tidy` to update any new dependencies - [ ] I have run `make lint` to verify my code passes the lint check - [ ] I have formatted my code using `gofumpt` <!--- Please provide details if the checkbox below is to be left unchecked. --> - [ ] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [ ] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Cloud, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Cloud API version <!-- @Pulumi employees: If yes, you must submit corresponding changes in the service repo. -->
2023-11-15 11:19:31 +00:00
close(eventChannel)
<-doneChannel
assert.Contains(t, stdout.String(), "Loading policy packs...")
}