pulumi/pkg/backend/display/query.go

129 lines
3.3 KiB
Go
Raw Normal View History

// Copyright 2016-2018, 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
import (
"fmt"
"math"
"os"
"time"
"github.com/pulumi/pulumi/pkg/v3/engine"
"github.com/pulumi/pulumi/sdk/v3/go/common/diag"
"github.com/pulumi/pulumi/sdk/v3/go/common/util/cmdutil"
"github.com/pulumi/pulumi/sdk/v3/go/common/util/contract"
)
// ShowQueryEvents displays query events on the CLI.
func ShowQueryEvents(op string, events <-chan engine.Event,
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
done chan<- bool, opts Options,
) {
prefix := fmt.Sprintf("%s%s...", cmdutil.EmojiOr("✨ ", "@ "), op)
var spinner cmdutil.Spinner
var ticker *time.Ticker
if opts.IsInteractive {
spinner, ticker = cmdutil.NewSpinnerAndTicker(prefix, nil, opts.Color, 8 /*timesPerSecond*/, opts.SuppressProgress)
} else {
spinner = &nopSpinner{}
ticker = time.NewTicker(math.MaxInt64)
}
defer func() {
spinner.Reset()
ticker.Stop()
close(done)
}()
for {
select {
case <-ticker.C:
spinner.Tick()
case event := <-events:
spinner.Reset()
out := os.Stdout
if event.Type == engine.DiagEvent {
payload := event.Payload().(engine.DiagEventPayload)
if payload.Severity == diag.Error || payload.Severity == diag.Warning {
out = os.Stderr
}
}
msg := renderQueryEvent(event, opts)
if msg != "" && out != nil {
fprintIgnoreError(out, msg)
}
if event.Type == engine.CancelEvent {
return
}
}
}
}
func renderQueryEvent(event engine.Event, opts Options) string {
switch event.Type {
case engine.CancelEvent:
return ""
case engine.StdoutColorEvent:
return renderStdoutColorEvent(event.Payload().(engine.StdoutEventPayload), opts)
// Includes stdout of the query process.
case engine.DiagEvent:
return renderQueryDiagEvent(event.Payload().(engine.DiagEventPayload), opts)
implement the engine bits for debugging support (#17072) We want to introduce dubugging support for Pulumi programs. This PR implements the engine changes necessary for that. Namely, we pass the information whether we expect a debugger to be started to the language runtime, and introduce a way for the language runtime plugins to report to the engine that we're waiting for a debugger to attach. The language runtime is expected to include the information relevant for the user to be able to attach to the debugger, as well as a shortened message. The idea is that the configuration can be picked up by an IDE, and the debugger can attach automatically. Meanwhile the short message should contain enough information to be able to attach a debugger manually, while being short enough to be displayed to the user in the CLI output. (this will commonly be either the port of the debugger, or the PID of the process being debugged). The implementation of the CLI flags and each of the language runtimes will follow in subsequent PRs. I tried adding a test to this, but I'm not sure it's possible with our current testing infrastructure. To do this properly, we'd need to make a RPC call to the engine, but we don't have that available in the lifecycletests (? please let me know if I'm missing something). Once more of the feature is implemented we might be able to implement an integration test for it. (Not straightforward either, as we'll have to tell the debugger to continue, but that should be more doable). Another thing that's not clear to me is that @EronWright mentions this could be used for MLC/provider debugging as well. However I'm not seeing how that's going to work, as MLCs/providers are being run as a binary plugin, which we don't compile from pulumi/pulumi, and thus wouldn't necessarily even know which debugger to launch it under without a bunch of additional configuration, that might be better in a shim around the program (or just keeping the debugging the way we're currently doing, launching the program and then letting the engine attach to it). --------- Co-authored-by: Eron Wright <eron@pulumi.com> Co-authored-by: Julien <julien@caffeine.lu>
2024-08-30 10:31:28 +00:00
case engine.StartDebuggingEvent:
return ""
case engine.PreludeEvent, engine.SummaryEvent, engine.ResourceOperationFailed,
engine.ResourceOutputsEvent, engine.ResourcePreEvent:
contract.Failf("query mode does not support resource operations")
return ""
turn on the golangci-lint exhaustive linter (#15028) Turn on the golangci-lint exhaustive linter. This is the first step towards catching more missing cases during development rather than in tests, or in production. This might be best reviewed commit-by-commit, as the first commit turns on the linter with the `default-signifies-exhaustive: true` option set, which requires a lot less changes in the current codebase. I think it's probably worth doing the second commit as well, as that will get us the real benefits, even though we end up with a little bit more churn. However it means all the `switch` statements are covered, which isn't the case after the first commit, since we do have a lot of `default` statements that just call `assert.Fail`. Fixes #14601 ## 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 - [x] 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. -->
2024-01-17 16:50:41 +00:00
case engine.PolicyLoadEvent, engine.PolicyViolationEvent, engine.PolicyRemediationEvent:
return ""
Use events to report downloads as system messages (#17019) When running a Pulumi operation such as a preview or an update, Pulumi will detect if plugins (e.g. an AWS provider) are missing and download and install them appropriately. Presently the user experience when this happens isn't great (see e.g. https://github.com/pulumi/pulumi/issues/14250), making it hard for the user to see what is happening/what is taking so long when required plugins are large. This commit attempts to rectify this by continuing the work in https://github.com/pulumi/pulumi/pull/16094 that tracks download progress using engine events. In doing so, we are able to render multiple downloads as part of the existing "system messages" panel in the Pulumi output, and provide a clean view of what is going on when downloads must occur before program execution. Moreover, we generalise that PR to handle any engine process, enabling us to play a similar trick with plugin installations (which can also take a while). To preserve existing behaviour, we introduce a new class for these events which we call "ephemeral", meaning that they are not persisted or rendered in contexts such as diffs, for instance. Specifically, ephemeral events are *not* sent to HTTP backends (i.e. the service), so this commit should not require any changes to the service before merging and releasing. Fixes #14250 Closes #16094 Closes #16937 https://github.com/user-attachments/assets/f0fac5e9-b3c8-4ea7-9cb7-075fc4b625d9 https://github.com/user-attachments/assets/7a761aa9-10ad-4f66-afa3-e4550b4553a5
2024-09-03 12:12:04 +00:00
case engine.ProgressEvent:
return ""
default:
contract.Failf("unknown event type '%s'", event.Type)
return ""
}
}
func renderQueryDiagEvent(payload engine.DiagEventPayload, opts Options) string {
// Ignore debug messages unless we're in debug mode.
if payload.Severity == diag.Debug && !opts.Debug {
return ""
}
// Ignore error messages reported through diag events -- these are reported as errors later.
if payload.Severity == diag.Infoerr {
return ""
}
// For stdout messages, trim ONLY the last newline character.
if payload.Severity == diag.Info {
payload.Message = cmdutil.RemoveTrailingNewline(payload.Message)
}
return opts.Color.Colorize(payload.Prefix + payload.Message)
}