2018-05-22 19:43:36 +00:00
|
|
|
// 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.
|
|
|
|
|
2017-10-05 21:08:46 +00:00
|
|
|
package engine
|
|
|
|
|
|
|
|
import (
|
|
|
|
"bytes"
|
|
|
|
"fmt"
|
|
|
|
|
2021-03-17 13:20:05 +00:00
|
|
|
"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/util/contract"
|
|
|
|
"github.com/pulumi/pulumi/sdk/v3/go/common/util/logging"
|
2017-10-05 21:08:46 +00:00
|
|
|
)
|
|
|
|
|
Implement status sinks
This commit reverts most of #1853 and replaces it with functionally
identical logic, using the notion of status message-specific sinks.
In other words, where the original commit implemented ephemeral status
messages by adding an `isStatus` parameter to most of the logging
methdos in pulumi/pulumi, this implements ephemeral status messages as a
parallel logging sink, which emits _only_ ephemeral status messages.
The original commit message in that PR was:
> Allow log events to be marked "status" events
>
> This commit will introduce a field, IsStatus to LogRequest. A "status"
> logging event will be displayed in the Info column of the main
> display, but will not be printed out at the end, when resource
> operations complete.
>
> For example, for complex resource initialization, we'd like to display
> a series of intermediate results: [1/4] Service object created, for
> example. We'd like these to appear in the Info column, but not at the
> end, where they are not helpful to the user.
2018-08-31 20:12:40 +00:00
|
|
|
func newEventSink(events eventEmitter, statusSink bool) diag.Sink {
|
2017-10-05 21:08:46 +00:00
|
|
|
return &eventSink{
|
Implement status sinks
This commit reverts most of #1853 and replaces it with functionally
identical logic, using the notion of status message-specific sinks.
In other words, where the original commit implemented ephemeral status
messages by adding an `isStatus` parameter to most of the logging
methdos in pulumi/pulumi, this implements ephemeral status messages as a
parallel logging sink, which emits _only_ ephemeral status messages.
The original commit message in that PR was:
> Allow log events to be marked "status" events
>
> This commit will introduce a field, IsStatus to LogRequest. A "status"
> logging event will be displayed in the Info column of the main
> display, but will not be printed out at the end, when resource
> operations complete.
>
> For example, for complex resource initialization, we'd like to display
> a series of intermediate results: [1/4] Service object created, for
> example. We'd like these to appear in the Info column, but not at the
> end, where they are not helpful to the user.
2018-08-31 20:12:40 +00:00
|
|
|
events: events,
|
|
|
|
statusSink: statusSink,
|
2017-10-05 21:08:46 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// eventSink is a sink which writes all events to a channel
|
|
|
|
type eventSink struct {
|
Implement status sinks
This commit reverts most of #1853 and replaces it with functionally
identical logic, using the notion of status message-specific sinks.
In other words, where the original commit implemented ephemeral status
messages by adding an `isStatus` parameter to most of the logging
methdos in pulumi/pulumi, this implements ephemeral status messages as a
parallel logging sink, which emits _only_ ephemeral status messages.
The original commit message in that PR was:
> Allow log events to be marked "status" events
>
> This commit will introduce a field, IsStatus to LogRequest. A "status"
> logging event will be displayed in the Info column of the main
> display, but will not be printed out at the end, when resource
> operations complete.
>
> For example, for complex resource initialization, we'd like to display
> a series of intermediate results: [1/4] Service object created, for
> example. We'd like these to appear in the Info column, but not at the
> end, where they are not helpful to the user.
2018-08-31 20:12:40 +00:00
|
|
|
events eventEmitter // the channel to emit events into.
|
|
|
|
statusSink bool // whether this is an event sink for status messages.
|
2017-10-05 21:08:46 +00:00
|
|
|
}
|
|
|
|
|
2018-08-31 19:33:01 +00:00
|
|
|
func (s *eventSink) Logf(sev diag.Severity, d *diag.Diag, args ...interface{}) {
|
2017-10-05 21:08:46 +00:00
|
|
|
switch sev {
|
|
|
|
case diag.Debug:
|
2018-08-31 19:33:01 +00:00
|
|
|
s.Debugf(d, args...)
|
2017-10-05 21:08:46 +00:00
|
|
|
case diag.Info:
|
2018-08-31 19:33:01 +00:00
|
|
|
s.Infof(d, args...)
|
2017-10-05 21:08:46 +00:00
|
|
|
case diag.Infoerr:
|
2018-08-31 19:33:01 +00:00
|
|
|
s.Infoerrf(d, args...)
|
2017-10-05 21:08:46 +00:00
|
|
|
case diag.Warning:
|
2018-08-31 19:33:01 +00:00
|
|
|
s.Warningf(d, args...)
|
2017-10-05 21:08:46 +00:00
|
|
|
case diag.Error:
|
2018-08-31 19:33:01 +00:00
|
|
|
s.Errorf(d, args...)
|
2017-10-05 21:08:46 +00:00
|
|
|
default:
|
|
|
|
contract.Failf("Unrecognized severity: %v", sev)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-08-31 19:33:01 +00:00
|
|
|
func (s *eventSink) Debugf(d *diag.Diag, args ...interface{}) {
|
2017-10-05 21:08:46 +00:00
|
|
|
// For debug messages, write both to the glogger and a stream, if there is one.
|
2018-05-15 22:28:00 +00:00
|
|
|
logging.V(3).Infof(d.Message, args...)
|
2018-05-07 22:11:52 +00:00
|
|
|
prefix, msg := s.Stringify(diag.Debug, d, args...)
|
2018-05-15 22:28:00 +00:00
|
|
|
if logging.V(9) {
|
|
|
|
logging.V(9).Infof("eventSink::Debug(%v)", msg[:len(msg)-1])
|
2017-10-05 21:08:46 +00:00
|
|
|
}
|
Implement status sinks
This commit reverts most of #1853 and replaces it with functionally
identical logic, using the notion of status message-specific sinks.
In other words, where the original commit implemented ephemeral status
messages by adding an `isStatus` parameter to most of the logging
methdos in pulumi/pulumi, this implements ephemeral status messages as a
parallel logging sink, which emits _only_ ephemeral status messages.
The original commit message in that PR was:
> Allow log events to be marked "status" events
>
> This commit will introduce a field, IsStatus to LogRequest. A "status"
> logging event will be displayed in the Info column of the main
> display, but will not be printed out at the end, when resource
> operations complete.
>
> For example, for complex resource initialization, we'd like to display
> a series of intermediate results: [1/4] Service object created, for
> example. We'd like these to appear in the Info column, but not at the
> end, where they are not helpful to the user.
2018-08-31 20:12:40 +00:00
|
|
|
s.events.diagDebugEvent(d, prefix, msg, s.statusSink)
|
2017-10-05 21:08:46 +00:00
|
|
|
}
|
|
|
|
|
2018-08-31 19:33:01 +00:00
|
|
|
func (s *eventSink) Infof(d *diag.Diag, args ...interface{}) {
|
2018-05-07 22:11:52 +00:00
|
|
|
prefix, msg := s.Stringify(diag.Info, d, args...)
|
2018-05-15 22:28:00 +00:00
|
|
|
if logging.V(5) {
|
|
|
|
logging.V(5).Infof("eventSink::Info(%v)", msg[:len(msg)-1])
|
2017-10-05 21:08:46 +00:00
|
|
|
}
|
Implement status sinks
This commit reverts most of #1853 and replaces it with functionally
identical logic, using the notion of status message-specific sinks.
In other words, where the original commit implemented ephemeral status
messages by adding an `isStatus` parameter to most of the logging
methdos in pulumi/pulumi, this implements ephemeral status messages as a
parallel logging sink, which emits _only_ ephemeral status messages.
The original commit message in that PR was:
> Allow log events to be marked "status" events
>
> This commit will introduce a field, IsStatus to LogRequest. A "status"
> logging event will be displayed in the Info column of the main
> display, but will not be printed out at the end, when resource
> operations complete.
>
> For example, for complex resource initialization, we'd like to display
> a series of intermediate results: [1/4] Service object created, for
> example. We'd like these to appear in the Info column, but not at the
> end, where they are not helpful to the user.
2018-08-31 20:12:40 +00:00
|
|
|
s.events.diagInfoEvent(d, prefix, msg, s.statusSink)
|
2017-10-05 21:08:46 +00:00
|
|
|
}
|
|
|
|
|
2018-08-31 19:33:01 +00:00
|
|
|
func (s *eventSink) Infoerrf(d *diag.Diag, args ...interface{}) {
|
2018-05-07 22:11:52 +00:00
|
|
|
prefix, msg := s.Stringify(diag.Info /* not Infoerr, just "info: "*/, d, args...)
|
2018-05-15 22:28:00 +00:00
|
|
|
if logging.V(5) {
|
|
|
|
logging.V(5).Infof("eventSink::Infoerr(%v)", msg[:len(msg)-1])
|
2017-10-05 21:08:46 +00:00
|
|
|
}
|
Implement status sinks
This commit reverts most of #1853 and replaces it with functionally
identical logic, using the notion of status message-specific sinks.
In other words, where the original commit implemented ephemeral status
messages by adding an `isStatus` parameter to most of the logging
methdos in pulumi/pulumi, this implements ephemeral status messages as a
parallel logging sink, which emits _only_ ephemeral status messages.
The original commit message in that PR was:
> Allow log events to be marked "status" events
>
> This commit will introduce a field, IsStatus to LogRequest. A "status"
> logging event will be displayed in the Info column of the main
> display, but will not be printed out at the end, when resource
> operations complete.
>
> For example, for complex resource initialization, we'd like to display
> a series of intermediate results: [1/4] Service object created, for
> example. We'd like these to appear in the Info column, but not at the
> end, where they are not helpful to the user.
2018-08-31 20:12:40 +00:00
|
|
|
s.events.diagInfoerrEvent(d, prefix, msg, s.statusSink)
|
2017-10-05 21:08:46 +00:00
|
|
|
}
|
|
|
|
|
2018-08-31 19:33:01 +00:00
|
|
|
func (s *eventSink) Errorf(d *diag.Diag, args ...interface{}) {
|
2018-05-07 22:11:52 +00:00
|
|
|
prefix, msg := s.Stringify(diag.Error, d, args...)
|
2018-05-15 22:28:00 +00:00
|
|
|
if logging.V(5) {
|
|
|
|
logging.V(5).Infof("eventSink::Error(%v)", msg[:len(msg)-1])
|
2017-10-05 21:08:46 +00:00
|
|
|
}
|
Implement status sinks
This commit reverts most of #1853 and replaces it with functionally
identical logic, using the notion of status message-specific sinks.
In other words, where the original commit implemented ephemeral status
messages by adding an `isStatus` parameter to most of the logging
methdos in pulumi/pulumi, this implements ephemeral status messages as a
parallel logging sink, which emits _only_ ephemeral status messages.
The original commit message in that PR was:
> Allow log events to be marked "status" events
>
> This commit will introduce a field, IsStatus to LogRequest. A "status"
> logging event will be displayed in the Info column of the main
> display, but will not be printed out at the end, when resource
> operations complete.
>
> For example, for complex resource initialization, we'd like to display
> a series of intermediate results: [1/4] Service object created, for
> example. We'd like these to appear in the Info column, but not at the
> end, where they are not helpful to the user.
2018-08-31 20:12:40 +00:00
|
|
|
s.events.diagErrorEvent(d, prefix, msg, s.statusSink)
|
2017-10-05 21:08:46 +00:00
|
|
|
}
|
|
|
|
|
2018-08-31 19:33:01 +00:00
|
|
|
func (s *eventSink) Warningf(d *diag.Diag, args ...interface{}) {
|
2018-05-07 22:11:52 +00:00
|
|
|
prefix, msg := s.Stringify(diag.Warning, d, args...)
|
2018-05-15 22:28:00 +00:00
|
|
|
if logging.V(5) {
|
|
|
|
logging.V(5).Infof("eventSink::Warning(%v)", msg[:len(msg)-1])
|
2017-10-05 21:08:46 +00:00
|
|
|
}
|
Implement status sinks
This commit reverts most of #1853 and replaces it with functionally
identical logic, using the notion of status message-specific sinks.
In other words, where the original commit implemented ephemeral status
messages by adding an `isStatus` parameter to most of the logging
methdos in pulumi/pulumi, this implements ephemeral status messages as a
parallel logging sink, which emits _only_ ephemeral status messages.
The original commit message in that PR was:
> Allow log events to be marked "status" events
>
> This commit will introduce a field, IsStatus to LogRequest. A "status"
> logging event will be displayed in the Info column of the main
> display, but will not be printed out at the end, when resource
> operations complete.
>
> For example, for complex resource initialization, we'd like to display
> a series of intermediate results: [1/4] Service object created, for
> example. We'd like these to appear in the Info column, but not at the
> end, where they are not helpful to the user.
2018-08-31 20:12:40 +00:00
|
|
|
s.events.diagWarningEvent(d, prefix, msg, s.statusSink)
|
2017-10-05 21:08:46 +00:00
|
|
|
}
|
|
|
|
|
2018-05-07 22:11:52 +00:00
|
|
|
func (s *eventSink) Stringify(sev diag.Severity, d *diag.Diag, args ...interface{}) (string, string) {
|
|
|
|
var prefix bytes.Buffer
|
Make a smattering of CLI UX improvements
Since I was digging around over the weekend after the change to move
away from light black, and the impact it had on less important
information showing more prominently than it used to, I took a step
back and did a deeper tidying up of things. Another side goal of this
exercise was to be a little more respectful of terminal width; when
we could say things with fewer words, I did so.
* Stylize the preview/update summary differently, so that it stands
out as a section. Also highlight the total changes with bold -- it
turns out this has a similar effect to the bright white colorization,
just without the negative effects on e.g. white terminals.
* Eliminate some verbosity in the phrasing of change summaries.
* Make all heading sections stylized consistently. This includes
the color (bright magenta) and the vertical spacing (always a newline
separating headings). We were previously inconsistent on this (e.g.,
outputs were under "---outputs---"). Now the headings are:
Previewing (etc), Diagnostics, Outputs, Resources, Duration, and Permalink.
* Fix an issue where we'd parent things to "global" until the stack
object later showed up. Now we'll simply mock up a stack resource.
* Don't show messages like "no change" or "unchanged". Prior to the
light black removal, these faded into the background of the terminal.
Now they just clutter up the display. Similar to the elision of "*"
for OpSames in a prior commit, just leave these out. Now anything
that's written is actually a meaningful status for the user to note.
* Don't show the "3 info messages," etc. summaries in the Info column
while an update is ongoing. Instead, just show the latest line. This
is more respectful of width -- I often find that the important
messages scroll off the right of my screen before this change.
For discussion:
- I actually wonder if we should eliminate the summary
altogether and always just show the latest line. Or even
blank it out. The summary feels better suited for the
Diagnostics section, and the Status concisely tells us
how a resource's update ended up (failed, succeeded, etc).
- Similarly, I question the idea of showing only the "worst"
message. I'd vote for always showing the latest, and again
leaving it to the Status column for concisely telling the
user about the final state a resource ended up in.
* Stop prepending "info: " to every stdout/stderr message. It adds
no value, clutters up the display, and worsens horizontal usage.
* Lessen the verbosity of update headline messages, so we now instead
of e.g. "Previewing update of stack 'x':", we just say
"Previewing update (x):".
* Eliminate vertical whitespace in the Diagnostics section. Every
independent console.out previously was separated by an entire newline,
which made the section look cluttered to my eyes. These are just
streams of logs, there's no reason for the extra newlines.
* Colorize the resource headers in the Diagnostic section light blue.
Note that this will change various test baselines, which I will
update next. I didn't want those in the same commit.
2018-09-24 15:31:19 +00:00
|
|
|
if sev != diag.Info && sev != diag.Infoerr {
|
|
|
|
// Unless it's an ordinary stdout message, prepend the message category's prefix (error/warning).
|
|
|
|
switch sev {
|
|
|
|
case diag.Debug:
|
|
|
|
prefix.WriteString(colors.SpecDebug)
|
|
|
|
case diag.Error:
|
|
|
|
prefix.WriteString(colors.SpecError)
|
|
|
|
case diag.Warning:
|
|
|
|
prefix.WriteString(colors.SpecWarning)
|
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 diag.Info, diag.Infoerr:
|
|
|
|
// handled above
|
Make a smattering of CLI UX improvements
Since I was digging around over the weekend after the change to move
away from light black, and the impact it had on less important
information showing more prominently than it used to, I took a step
back and did a deeper tidying up of things. Another side goal of this
exercise was to be a little more respectful of terminal width; when
we could say things with fewer words, I did so.
* Stylize the preview/update summary differently, so that it stands
out as a section. Also highlight the total changes with bold -- it
turns out this has a similar effect to the bright white colorization,
just without the negative effects on e.g. white terminals.
* Eliminate some verbosity in the phrasing of change summaries.
* Make all heading sections stylized consistently. This includes
the color (bright magenta) and the vertical spacing (always a newline
separating headings). We were previously inconsistent on this (e.g.,
outputs were under "---outputs---"). Now the headings are:
Previewing (etc), Diagnostics, Outputs, Resources, Duration, and Permalink.
* Fix an issue where we'd parent things to "global" until the stack
object later showed up. Now we'll simply mock up a stack resource.
* Don't show messages like "no change" or "unchanged". Prior to the
light black removal, these faded into the background of the terminal.
Now they just clutter up the display. Similar to the elision of "*"
for OpSames in a prior commit, just leave these out. Now anything
that's written is actually a meaningful status for the user to note.
* Don't show the "3 info messages," etc. summaries in the Info column
while an update is ongoing. Instead, just show the latest line. This
is more respectful of width -- I often find that the important
messages scroll off the right of my screen before this change.
For discussion:
- I actually wonder if we should eliminate the summary
altogether and always just show the latest line. Or even
blank it out. The summary feels better suited for the
Diagnostics section, and the Status concisely tells us
how a resource's update ended up (failed, succeeded, etc).
- Similarly, I question the idea of showing only the "worst"
message. I'd vote for always showing the latest, and again
leaving it to the Status column for concisely telling the
user about the final state a resource ended up in.
* Stop prepending "info: " to every stdout/stderr message. It adds
no value, clutters up the display, and worsens horizontal usage.
* Lessen the verbosity of update headline messages, so we now instead
of e.g. "Previewing update of stack 'x':", we just say
"Previewing update (x):".
* Eliminate vertical whitespace in the Diagnostics section. Every
independent console.out previously was separated by an entire newline,
which made the section look cluttered to my eyes. These are just
streams of logs, there's no reason for the extra newlines.
* Colorize the resource headers in the Diagnostic section light blue.
Note that this will change various test baselines, which I will
update next. I didn't want those in the same commit.
2018-09-24 15:31:19 +00:00
|
|
|
default:
|
|
|
|
contract.Failf("Unrecognized diagnostic severity: %v", sev)
|
|
|
|
}
|
|
|
|
|
|
|
|
prefix.WriteString(string(sev))
|
|
|
|
prefix.WriteString(": ")
|
|
|
|
prefix.WriteString(colors.Reset)
|
2017-10-05 21:08:46 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// Finally, actually print the message itself.
|
2018-05-07 22:11:52 +00:00
|
|
|
var buffer bytes.Buffer
|
2017-12-14 19:53:02 +00:00
|
|
|
buffer.WriteString(colors.SpecNote)
|
2017-10-05 21:08:46 +00:00
|
|
|
|
2017-11-14 19:26:41 +00:00
|
|
|
if d.Raw {
|
|
|
|
buffer.WriteString(d.Message)
|
|
|
|
} else {
|
2023-02-23 21:14:41 +00:00
|
|
|
fmt.Fprintf(&buffer, d.Message, args...)
|
2017-11-14 19:26:41 +00:00
|
|
|
}
|
2017-10-05 21:08:46 +00:00
|
|
|
|
2017-12-14 19:53:02 +00:00
|
|
|
buffer.WriteString(colors.Reset)
|
2017-10-05 21:08:46 +00:00
|
|
|
buffer.WriteRune('\n')
|
|
|
|
|
|
|
|
// TODO[pulumi/pulumi#15]: support Clang-style expressive diagnostics. This would entail, for example, using
|
|
|
|
// the buffer within the target document, to demonstrate the offending line/column range of code.
|
|
|
|
|
2018-05-07 22:11:52 +00:00
|
|
|
return prefix.String(), buffer.String()
|
2017-10-05 21:08:46 +00:00
|
|
|
}
|