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.
|
2016-11-15 19:30:34 +00:00
|
|
|
|
|
|
|
package diag
|
|
|
|
|
|
|
|
import (
|
|
|
|
"bytes"
|
|
|
|
"fmt"
|
2023-02-15 01:06:56 +00:00
|
|
|
"io"
|
2023-03-23 23:11:27 +00:00
|
|
|
"sync"
|
2023-02-15 01:06:56 +00:00
|
|
|
|
2021-03-17 13:20:05 +00:00
|
|
|
"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"
|
2016-11-15 19:30:34 +00:00
|
|
|
)
|
|
|
|
|
|
|
|
// Sink facilitates pluggable diagnostics messages.
|
|
|
|
type Sink interface {
|
Introduce an interface to read config
This change adds an engine gRPC interface, and associated implementation,
so that plugins may do interesting things that require "phoning home".
Previously, the engine would fire up plugins and talk to them directly,
but there was no way for a plugin to ask the engine to do anything.
The motivation here is so that plugins can read evaluator state, such
as config information, but this change also allows richer logging
functionality than previously possible. We will still auto-log any
stdout/stderr writes; however, explicit errors, warnings, informational,
and even debug messages may be written over the Log API.
2017-06-21 02:45:07 +00:00
|
|
|
// Logf issues a log message.
|
2018-08-31 19:33:01 +00:00
|
|
|
Logf(sev Severity, diag *Diag, args ...interface{})
|
Introduce an interface to read config
This change adds an engine gRPC interface, and associated implementation,
so that plugins may do interesting things that require "phoning home".
Previously, the engine would fire up plugins and talk to them directly,
but there was no way for a plugin to ask the engine to do anything.
The motivation here is so that plugins can read evaluator state, such
as config information, but this change also allows richer logging
functionality than previously possible. We will still auto-log any
stdout/stderr writes; however, explicit errors, warnings, informational,
and even debug messages may be written over the Log API.
2017-06-21 02:45:07 +00:00
|
|
|
// Debugf issues a debugging message.
|
2018-08-31 19:33:01 +00:00
|
|
|
Debugf(diag *Diag, args ...interface{})
|
Improve output formatting
This change improves our output formatting by generally adding
fewer prefixes. As shown in pulumi/pulumi#359, we were being
excessively verbose in many places, including prefixing every
console.out with "langhost[nodejs].stdout: ", displaying full
stack traces for simple errors like missing configuration, etc.
Overall, this change includes the following:
* Don't prefix stdout and stderr output from the program, other
than the standard "info:" prefix. I experimented with various
schemes here, but they all felt gratuitous. Simply emitting
the output seems fine, especially as it's closer to what would
happen if you just ran the program under node.
* Do NOT make writes to stderr fail the plan/deploy. Previously
we assumed that any console.errors, for instance, meant that
the overall program should fail. This simply isn't how stderr
is treated generally and meant you couldn't use certain
logging techniques and libraries, among other things.
* Do make sure that stderr writes in the program end up going to
stderr in the Pulumi CLI output, however, so that redirection
works as it should. This required a new Infoerr log level.
* Make a small fix to the planning logic so we don't attempt to
print the summary if an error occurs.
* Finally, add a new error type, RunError, that when thrown and
uncaught does not result in a full stack trace being printed.
Anyone can use this, however, we currently use it for config
errors so that we can terminate with a pretty error message,
rather than the monstrosity shown in pulumi/pulumi#359.
2017-09-23 12:20:11 +00:00
|
|
|
// Infof issues an informational message (to stdout).
|
2018-08-31 19:33:01 +00:00
|
|
|
Infof(diag *Diag, args ...interface{})
|
Improve output formatting
This change improves our output formatting by generally adding
fewer prefixes. As shown in pulumi/pulumi#359, we were being
excessively verbose in many places, including prefixing every
console.out with "langhost[nodejs].stdout: ", displaying full
stack traces for simple errors like missing configuration, etc.
Overall, this change includes the following:
* Don't prefix stdout and stderr output from the program, other
than the standard "info:" prefix. I experimented with various
schemes here, but they all felt gratuitous. Simply emitting
the output seems fine, especially as it's closer to what would
happen if you just ran the program under node.
* Do NOT make writes to stderr fail the plan/deploy. Previously
we assumed that any console.errors, for instance, meant that
the overall program should fail. This simply isn't how stderr
is treated generally and meant you couldn't use certain
logging techniques and libraries, among other things.
* Do make sure that stderr writes in the program end up going to
stderr in the Pulumi CLI output, however, so that redirection
works as it should. This required a new Infoerr log level.
* Make a small fix to the planning logic so we don't attempt to
print the summary if an error occurs.
* Finally, add a new error type, RunError, that when thrown and
uncaught does not result in a full stack trace being printed.
Anyone can use this, however, we currently use it for config
errors so that we can terminate with a pretty error message,
rather than the monstrosity shown in pulumi/pulumi#359.
2017-09-23 12:20:11 +00:00
|
|
|
// Infoerrf issues an informational message (to stderr).
|
2018-08-31 19:33:01 +00:00
|
|
|
Infoerrf(diag *Diag, args ...interface{})
|
2017-02-23 02:53:36 +00:00
|
|
|
// Errorf issues a new error diagnostic.
|
2018-08-31 19:33:01 +00:00
|
|
|
Errorf(diag *Diag, args ...interface{})
|
2017-02-23 02:53:36 +00:00
|
|
|
// Warningf issues a new warning diagnostic.
|
2018-08-31 19:33:01 +00:00
|
|
|
Warningf(diag *Diag, args ...interface{})
|
2016-11-16 03:16:02 +00:00
|
|
|
|
2018-05-07 22:11:52 +00:00
|
|
|
// Stringify stringifies a diagnostic into a prefix and message that is appropriate for printing.
|
|
|
|
Stringify(sev Severity, diag *Diag, args ...interface{}) (string, string)
|
2017-02-10 01:26:49 +00:00
|
|
|
}
|
|
|
|
|
Introduce an interface to read config
This change adds an engine gRPC interface, and associated implementation,
so that plugins may do interesting things that require "phoning home".
Previously, the engine would fire up plugins and talk to them directly,
but there was no way for a plugin to ask the engine to do anything.
The motivation here is so that plugins can read evaluator state, such
as config information, but this change also allows richer logging
functionality than previously possible. We will still auto-log any
stdout/stderr writes; however, explicit errors, warnings, informational,
and even debug messages may be written over the Log API.
2017-06-21 02:45:07 +00:00
|
|
|
// Severity dictates the kind of diagnostic.
|
|
|
|
type Severity string
|
2017-02-10 01:26:49 +00:00
|
|
|
|
|
|
|
const (
|
Introduce an interface to read config
This change adds an engine gRPC interface, and associated implementation,
so that plugins may do interesting things that require "phoning home".
Previously, the engine would fire up plugins and talk to them directly,
but there was no way for a plugin to ask the engine to do anything.
The motivation here is so that plugins can read evaluator state, such
as config information, but this change also allows richer logging
functionality than previously possible. We will still auto-log any
stdout/stderr writes; however, explicit errors, warnings, informational,
and even debug messages may be written over the Log API.
2017-06-21 02:45:07 +00:00
|
|
|
Debug Severity = "debug"
|
|
|
|
Info Severity = "info"
|
Improve output formatting
This change improves our output formatting by generally adding
fewer prefixes. As shown in pulumi/pulumi#359, we were being
excessively verbose in many places, including prefixing every
console.out with "langhost[nodejs].stdout: ", displaying full
stack traces for simple errors like missing configuration, etc.
Overall, this change includes the following:
* Don't prefix stdout and stderr output from the program, other
than the standard "info:" prefix. I experimented with various
schemes here, but they all felt gratuitous. Simply emitting
the output seems fine, especially as it's closer to what would
happen if you just ran the program under node.
* Do NOT make writes to stderr fail the plan/deploy. Previously
we assumed that any console.errors, for instance, meant that
the overall program should fail. This simply isn't how stderr
is treated generally and meant you couldn't use certain
logging techniques and libraries, among other things.
* Do make sure that stderr writes in the program end up going to
stderr in the Pulumi CLI output, however, so that redirection
works as it should. This required a new Infoerr log level.
* Make a small fix to the planning logic so we don't attempt to
print the summary if an error occurs.
* Finally, add a new error type, RunError, that when thrown and
uncaught does not result in a full stack trace being printed.
Anyone can use this, however, we currently use it for config
errors so that we can terminate with a pretty error message,
rather than the monstrosity shown in pulumi/pulumi#359.
2017-09-23 12:20:11 +00:00
|
|
|
Infoerr Severity = "info#err"
|
Introduce an interface to read config
This change adds an engine gRPC interface, and associated implementation,
so that plugins may do interesting things that require "phoning home".
Previously, the engine would fire up plugins and talk to them directly,
but there was no way for a plugin to ask the engine to do anything.
The motivation here is so that plugins can read evaluator state, such
as config information, but this change also allows richer logging
functionality than previously possible. We will still auto-log any
stdout/stderr writes; however, explicit errors, warnings, informational,
and even debug messages may be written over the Log API.
2017-06-21 02:45:07 +00:00
|
|
|
Warning Severity = "warning"
|
|
|
|
Error Severity = "error"
|
2017-02-10 01:26:49 +00:00
|
|
|
)
|
|
|
|
|
|
|
|
// FormatOptions controls the output style and content.
|
|
|
|
type FormatOptions struct {
|
2017-12-18 19:42:32 +00:00
|
|
|
Pwd string // the working directory.
|
|
|
|
Color colors.Colorization // how output should be colorized.
|
|
|
|
Debug bool // if true, debugging will be output to stdout.
|
2016-11-15 19:30:34 +00:00
|
|
|
}
|
|
|
|
|
2017-01-27 23:42:39 +00:00
|
|
|
// DefaultSink returns a default sink that simply logs output to stderr/stdout.
|
2017-10-05 21:08:46 +00:00
|
|
|
func DefaultSink(stdout io.Writer, stderr io.Writer, opts FormatOptions) Sink {
|
2023-02-15 01:06:56 +00:00
|
|
|
contract.Requiref(stdout != nil, "stdout", "must not be nil")
|
|
|
|
contract.Requiref(stderr != nil, "stderr", "must not be nil")
|
2023-03-23 23:11:27 +00:00
|
|
|
|
|
|
|
stdoutMu := &sync.Mutex{}
|
|
|
|
stderrMu := &sync.Mutex{}
|
|
|
|
func() {
|
|
|
|
defer func() {
|
|
|
|
// The == check below can panic if stdout and stderr are not comparable.
|
|
|
|
// If that happens, ignore the panic and use separate mutexes.
|
|
|
|
_ = recover()
|
|
|
|
}()
|
|
|
|
|
|
|
|
if stdout == stderr {
|
|
|
|
// If stdout and stderr point to the same stream,
|
|
|
|
// use the same mutex for them.
|
|
|
|
stderrMu = stdoutMu
|
|
|
|
}
|
|
|
|
}()
|
|
|
|
|
|
|
|
// Wrap the stdout and stderr writers in a mutex
|
|
|
|
// to ensure that we don't interleave output.
|
|
|
|
stdout = &syncWriter{Writer: stdout, mu: stdoutMu}
|
|
|
|
stderr = &syncWriter{Writer: stderr, mu: stderrMu}
|
|
|
|
|
Improve output formatting
This change improves our output formatting by generally adding
fewer prefixes. As shown in pulumi/pulumi#359, we were being
excessively verbose in many places, including prefixing every
console.out with "langhost[nodejs].stdout: ", displaying full
stack traces for simple errors like missing configuration, etc.
Overall, this change includes the following:
* Don't prefix stdout and stderr output from the program, other
than the standard "info:" prefix. I experimented with various
schemes here, but they all felt gratuitous. Simply emitting
the output seems fine, especially as it's closer to what would
happen if you just ran the program under node.
* Do NOT make writes to stderr fail the plan/deploy. Previously
we assumed that any console.errors, for instance, meant that
the overall program should fail. This simply isn't how stderr
is treated generally and meant you couldn't use certain
logging techniques and libraries, among other things.
* Do make sure that stderr writes in the program end up going to
stderr in the Pulumi CLI output, however, so that redirection
works as it should. This required a new Infoerr log level.
* Make a small fix to the planning logic so we don't attempt to
print the summary if an error occurs.
* Finally, add a new error type, RunError, that when thrown and
uncaught does not result in a full stack trace being printed.
Anyone can use this, however, we currently use it for config
errors so that we can terminate with a pretty error message,
rather than the monstrosity shown in pulumi/pulumi#359.
2017-09-23 12:20:11 +00:00
|
|
|
// Discard debug output by default unless requested.
|
2022-10-09 14:58:33 +00:00
|
|
|
debug := io.Discard
|
2017-07-14 00:09:46 +00:00
|
|
|
if opts.Debug {
|
2017-08-23 00:46:06 +00:00
|
|
|
debug = stdout
|
2017-07-14 00:09:46 +00:00
|
|
|
}
|
2023-03-23 23:11:27 +00:00
|
|
|
|
Introduce an interface to read config
This change adds an engine gRPC interface, and associated implementation,
so that plugins may do interesting things that require "phoning home".
Previously, the engine would fire up plugins and talk to them directly,
but there was no way for a plugin to ask the engine to do anything.
The motivation here is so that plugins can read evaluator state, such
as config information, but this change also allows richer logging
functionality than previously possible. We will still auto-log any
stdout/stderr writes; however, explicit errors, warnings, informational,
and even debug messages may be written over the Log API.
2017-06-21 02:45:07 +00:00
|
|
|
return newDefaultSink(opts, map[Severity]io.Writer{
|
2017-07-14 00:09:46 +00:00
|
|
|
Debug: debug,
|
2017-08-23 00:46:06 +00:00
|
|
|
Info: stdout,
|
Improve output formatting
This change improves our output formatting by generally adding
fewer prefixes. As shown in pulumi/pulumi#359, we were being
excessively verbose in many places, including prefixing every
console.out with "langhost[nodejs].stdout: ", displaying full
stack traces for simple errors like missing configuration, etc.
Overall, this change includes the following:
* Don't prefix stdout and stderr output from the program, other
than the standard "info:" prefix. I experimented with various
schemes here, but they all felt gratuitous. Simply emitting
the output seems fine, especially as it's closer to what would
happen if you just ran the program under node.
* Do NOT make writes to stderr fail the plan/deploy. Previously
we assumed that any console.errors, for instance, meant that
the overall program should fail. This simply isn't how stderr
is treated generally and meant you couldn't use certain
logging techniques and libraries, among other things.
* Do make sure that stderr writes in the program end up going to
stderr in the Pulumi CLI output, however, so that redirection
works as it should. This required a new Infoerr log level.
* Make a small fix to the planning logic so we don't attempt to
print the summary if an error occurs.
* Finally, add a new error type, RunError, that when thrown and
uncaught does not result in a full stack trace being printed.
Anyone can use this, however, we currently use it for config
errors so that we can terminate with a pretty error message,
rather than the monstrosity shown in pulumi/pulumi#359.
2017-09-23 12:20:11 +00:00
|
|
|
Infoerr: stderr,
|
2017-08-23 00:46:06 +00:00
|
|
|
Error: stderr,
|
|
|
|
Warning: stderr,
|
2017-02-23 02:53:36 +00:00
|
|
|
})
|
2016-11-17 01:52:14 +00:00
|
|
|
}
|
|
|
|
|
Introduce an interface to read config
This change adds an engine gRPC interface, and associated implementation,
so that plugins may do interesting things that require "phoning home".
Previously, the engine would fire up plugins and talk to them directly,
but there was no way for a plugin to ask the engine to do anything.
The motivation here is so that plugins can read evaluator state, such
as config information, but this change also allows richer logging
functionality than previously possible. We will still auto-log any
stdout/stderr writes; however, explicit errors, warnings, informational,
and even debug messages may be written over the Log API.
2017-06-21 02:45:07 +00:00
|
|
|
func newDefaultSink(opts FormatOptions, writers map[Severity]io.Writer) *defaultSink {
|
2023-02-15 01:06:56 +00:00
|
|
|
contract.Assertf(writers[Debug] != nil, "Writer for %v must be set", Debug)
|
|
|
|
contract.Assertf(writers[Info] != nil, "Writer for %v must be set", Info)
|
|
|
|
contract.Assertf(writers[Infoerr] != nil, "Writer for %v must be set", Infoerr)
|
|
|
|
contract.Assertf(writers[Error] != nil, "Writer for %v must be set", Error)
|
|
|
|
contract.Assertf(writers[Warning] != nil, "Writer for %v must be set", Warning)
|
2022-04-01 19:22:35 +00:00
|
|
|
contract.Assertf(opts.Color != "", "FormatOptions.Color must be set")
|
2017-02-23 02:53:36 +00:00
|
|
|
return &defaultSink{
|
|
|
|
opts: opts,
|
|
|
|
writers: writers,
|
|
|
|
}
|
2016-11-15 19:30:34 +00:00
|
|
|
}
|
|
|
|
|
Improve output formatting
This change improves our output formatting by generally adding
fewer prefixes. As shown in pulumi/pulumi#359, we were being
excessively verbose in many places, including prefixing every
console.out with "langhost[nodejs].stdout: ", displaying full
stack traces for simple errors like missing configuration, etc.
Overall, this change includes the following:
* Don't prefix stdout and stderr output from the program, other
than the standard "info:" prefix. I experimented with various
schemes here, but they all felt gratuitous. Simply emitting
the output seems fine, especially as it's closer to what would
happen if you just ran the program under node.
* Do NOT make writes to stderr fail the plan/deploy. Previously
we assumed that any console.errors, for instance, meant that
the overall program should fail. This simply isn't how stderr
is treated generally and meant you couldn't use certain
logging techniques and libraries, among other things.
* Do make sure that stderr writes in the program end up going to
stderr in the Pulumi CLI output, however, so that redirection
works as it should. This required a new Infoerr log level.
* Make a small fix to the planning logic so we don't attempt to
print the summary if an error occurs.
* Finally, add a new error type, RunError, that when thrown and
uncaught does not result in a full stack trace being printed.
Anyone can use this, however, we currently use it for config
errors so that we can terminate with a pretty error message,
rather than the monstrosity shown in pulumi/pulumi#359.
2017-09-23 12:20:11 +00:00
|
|
|
const DefaultSinkIDPrefix = "PU"
|
2016-11-16 16:19:26 +00:00
|
|
|
|
2016-11-16 00:30:10 +00:00
|
|
|
// defaultSink is the default sink which logs output to stderr/stdout.
|
|
|
|
type defaultSink struct {
|
2017-02-23 02:53:36 +00:00
|
|
|
opts FormatOptions // a set of options that control output style and content.
|
Introduce an interface to read config
This change adds an engine gRPC interface, and associated implementation,
so that plugins may do interesting things that require "phoning home".
Previously, the engine would fire up plugins and talk to them directly,
but there was no way for a plugin to ask the engine to do anything.
The motivation here is so that plugins can read evaluator state, such
as config information, but this change also allows richer logging
functionality than previously possible. We will still auto-log any
stdout/stderr writes; however, explicit errors, warnings, informational,
and even debug messages may be written over the Log API.
2017-06-21 02:45:07 +00:00
|
|
|
writers map[Severity]io.Writer // the writers to use for each kind of diagnostic severity.
|
2016-11-15 19:30:34 +00:00
|
|
|
}
|
|
|
|
|
2018-08-31 19:33:01 +00:00
|
|
|
func (d *defaultSink) Logf(sev Severity, diag *Diag, args ...interface{}) {
|
Introduce an interface to read config
This change adds an engine gRPC interface, and associated implementation,
so that plugins may do interesting things that require "phoning home".
Previously, the engine would fire up plugins and talk to them directly,
but there was no way for a plugin to ask the engine to do anything.
The motivation here is so that plugins can read evaluator state, such
as config information, but this change also allows richer logging
functionality than previously possible. We will still auto-log any
stdout/stderr writes; however, explicit errors, warnings, informational,
and even debug messages may be written over the Log API.
2017-06-21 02:45:07 +00:00
|
|
|
switch sev {
|
|
|
|
case Debug:
|
2018-08-31 19:33:01 +00:00
|
|
|
d.Debugf(diag, args...)
|
Introduce an interface to read config
This change adds an engine gRPC interface, and associated implementation,
so that plugins may do interesting things that require "phoning home".
Previously, the engine would fire up plugins and talk to them directly,
but there was no way for a plugin to ask the engine to do anything.
The motivation here is so that plugins can read evaluator state, such
as config information, but this change also allows richer logging
functionality than previously possible. We will still auto-log any
stdout/stderr writes; however, explicit errors, warnings, informational,
and even debug messages may be written over the Log API.
2017-06-21 02:45:07 +00:00
|
|
|
case Info:
|
2018-08-31 19:33:01 +00:00
|
|
|
d.Infof(diag, args...)
|
Improve output formatting
This change improves our output formatting by generally adding
fewer prefixes. As shown in pulumi/pulumi#359, we were being
excessively verbose in many places, including prefixing every
console.out with "langhost[nodejs].stdout: ", displaying full
stack traces for simple errors like missing configuration, etc.
Overall, this change includes the following:
* Don't prefix stdout and stderr output from the program, other
than the standard "info:" prefix. I experimented with various
schemes here, but they all felt gratuitous. Simply emitting
the output seems fine, especially as it's closer to what would
happen if you just ran the program under node.
* Do NOT make writes to stderr fail the plan/deploy. Previously
we assumed that any console.errors, for instance, meant that
the overall program should fail. This simply isn't how stderr
is treated generally and meant you couldn't use certain
logging techniques and libraries, among other things.
* Do make sure that stderr writes in the program end up going to
stderr in the Pulumi CLI output, however, so that redirection
works as it should. This required a new Infoerr log level.
* Make a small fix to the planning logic so we don't attempt to
print the summary if an error occurs.
* Finally, add a new error type, RunError, that when thrown and
uncaught does not result in a full stack trace being printed.
Anyone can use this, however, we currently use it for config
errors so that we can terminate with a pretty error message,
rather than the monstrosity shown in pulumi/pulumi#359.
2017-09-23 12:20:11 +00:00
|
|
|
case Infoerr:
|
2018-08-31 19:33:01 +00:00
|
|
|
d.Infoerrf(diag, args...)
|
Introduce an interface to read config
This change adds an engine gRPC interface, and associated implementation,
so that plugins may do interesting things that require "phoning home".
Previously, the engine would fire up plugins and talk to them directly,
but there was no way for a plugin to ask the engine to do anything.
The motivation here is so that plugins can read evaluator state, such
as config information, but this change also allows richer logging
functionality than previously possible. We will still auto-log any
stdout/stderr writes; however, explicit errors, warnings, informational,
and even debug messages may be written over the Log API.
2017-06-21 02:45:07 +00:00
|
|
|
case Warning:
|
2018-08-31 19:33:01 +00:00
|
|
|
d.Warningf(diag, args...)
|
Introduce an interface to read config
This change adds an engine gRPC interface, and associated implementation,
so that plugins may do interesting things that require "phoning home".
Previously, the engine would fire up plugins and talk to them directly,
but there was no way for a plugin to ask the engine to do anything.
The motivation here is so that plugins can read evaluator state, such
as config information, but this change also allows richer logging
functionality than previously possible. We will still auto-log any
stdout/stderr writes; however, explicit errors, warnings, informational,
and even debug messages may be written over the Log API.
2017-06-21 02:45:07 +00:00
|
|
|
case Error:
|
2018-08-31 19:33:01 +00:00
|
|
|
d.Errorf(diag, args...)
|
Introduce an interface to read config
This change adds an engine gRPC interface, and associated implementation,
so that plugins may do interesting things that require "phoning home".
Previously, the engine would fire up plugins and talk to them directly,
but there was no way for a plugin to ask the engine to do anything.
The motivation here is so that plugins can read evaluator state, such
as config information, but this change also allows richer logging
functionality than previously possible. We will still auto-log any
stdout/stderr writes; however, explicit errors, warnings, informational,
and even debug messages may be written over the Log API.
2017-06-21 02:45:07 +00:00
|
|
|
default:
|
|
|
|
contract.Failf("Unrecognized severity: %v", sev)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-05-07 22:11:52 +00:00
|
|
|
func (d *defaultSink) createMessage(sev Severity, diag *Diag, args ...interface{}) string {
|
|
|
|
prefix, msg := d.Stringify(sev, diag, args...)
|
|
|
|
return prefix + msg
|
|
|
|
}
|
|
|
|
|
2018-08-31 19:33:01 +00:00
|
|
|
func (d *defaultSink) Debugf(diag *Diag, args ...interface{}) {
|
2017-07-14 00:09: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(diag.Message, args...)
|
2018-05-07 22:11:52 +00:00
|
|
|
msg := d.createMessage(Debug, diag, args...)
|
2018-05-15 22:28:00 +00:00
|
|
|
if logging.V(9) {
|
|
|
|
logging.V(9).Infof("defaultSink::Debug(%v)", msg[:len(msg)-1])
|
Introduce an interface to read config
This change adds an engine gRPC interface, and associated implementation,
so that plugins may do interesting things that require "phoning home".
Previously, the engine would fire up plugins and talk to them directly,
but there was no way for a plugin to ask the engine to do anything.
The motivation here is so that plugins can read evaluator state, such
as config information, but this change also allows richer logging
functionality than previously possible. We will still auto-log any
stdout/stderr writes; however, explicit errors, warnings, informational,
and even debug messages may be written over the Log API.
2017-06-21 02:45:07 +00:00
|
|
|
}
|
2023-03-23 23:11:27 +00:00
|
|
|
d.print(Debug, msg)
|
Introduce an interface to read config
This change adds an engine gRPC interface, and associated implementation,
so that plugins may do interesting things that require "phoning home".
Previously, the engine would fire up plugins and talk to them directly,
but there was no way for a plugin to ask the engine to do anything.
The motivation here is so that plugins can read evaluator state, such
as config information, but this change also allows richer logging
functionality than previously possible. We will still auto-log any
stdout/stderr writes; however, explicit errors, warnings, informational,
and even debug messages may be written over the Log API.
2017-06-21 02:45:07 +00:00
|
|
|
}
|
|
|
|
|
2018-08-31 19:33:01 +00:00
|
|
|
func (d *defaultSink) Infof(diag *Diag, args ...interface{}) {
|
2018-05-07 22:11:52 +00:00
|
|
|
msg := d.createMessage(Info, diag, args...)
|
2018-05-15 22:28:00 +00:00
|
|
|
if logging.V(5) {
|
|
|
|
logging.V(5).Infof("defaultSink::Info(%v)", msg[:len(msg)-1])
|
2017-02-23 02:53:36 +00:00
|
|
|
}
|
2023-03-23 23:11:27 +00:00
|
|
|
d.print(Info, msg)
|
2016-11-22 17:40:09 +00:00
|
|
|
}
|
|
|
|
|
2018-08-31 19:33:01 +00:00
|
|
|
func (d *defaultSink) Infoerrf(diag *Diag, args ...interface{}) {
|
2018-05-07 22:11:52 +00:00
|
|
|
msg := d.createMessage(Info /* not Infoerr, just "info: "*/, diag, args...)
|
2018-05-15 22:28:00 +00:00
|
|
|
if logging.V(5) {
|
|
|
|
logging.V(5).Infof("defaultSink::Infoerr(%v)", msg[:len(msg)-1])
|
Improve output formatting
This change improves our output formatting by generally adding
fewer prefixes. As shown in pulumi/pulumi#359, we were being
excessively verbose in many places, including prefixing every
console.out with "langhost[nodejs].stdout: ", displaying full
stack traces for simple errors like missing configuration, etc.
Overall, this change includes the following:
* Don't prefix stdout and stderr output from the program, other
than the standard "info:" prefix. I experimented with various
schemes here, but they all felt gratuitous. Simply emitting
the output seems fine, especially as it's closer to what would
happen if you just ran the program under node.
* Do NOT make writes to stderr fail the plan/deploy. Previously
we assumed that any console.errors, for instance, meant that
the overall program should fail. This simply isn't how stderr
is treated generally and meant you couldn't use certain
logging techniques and libraries, among other things.
* Do make sure that stderr writes in the program end up going to
stderr in the Pulumi CLI output, however, so that redirection
works as it should. This required a new Infoerr log level.
* Make a small fix to the planning logic so we don't attempt to
print the summary if an error occurs.
* Finally, add a new error type, RunError, that when thrown and
uncaught does not result in a full stack trace being printed.
Anyone can use this, however, we currently use it for config
errors so that we can terminate with a pretty error message,
rather than the monstrosity shown in pulumi/pulumi#359.
2017-09-23 12:20:11 +00:00
|
|
|
}
|
2023-03-23 23:11:27 +00:00
|
|
|
d.print(Infoerr, msg)
|
Improve output formatting
This change improves our output formatting by generally adding
fewer prefixes. As shown in pulumi/pulumi#359, we were being
excessively verbose in many places, including prefixing every
console.out with "langhost[nodejs].stdout: ", displaying full
stack traces for simple errors like missing configuration, etc.
Overall, this change includes the following:
* Don't prefix stdout and stderr output from the program, other
than the standard "info:" prefix. I experimented with various
schemes here, but they all felt gratuitous. Simply emitting
the output seems fine, especially as it's closer to what would
happen if you just ran the program under node.
* Do NOT make writes to stderr fail the plan/deploy. Previously
we assumed that any console.errors, for instance, meant that
the overall program should fail. This simply isn't how stderr
is treated generally and meant you couldn't use certain
logging techniques and libraries, among other things.
* Do make sure that stderr writes in the program end up going to
stderr in the Pulumi CLI output, however, so that redirection
works as it should. This required a new Infoerr log level.
* Make a small fix to the planning logic so we don't attempt to
print the summary if an error occurs.
* Finally, add a new error type, RunError, that when thrown and
uncaught does not result in a full stack trace being printed.
Anyone can use this, however, we currently use it for config
errors so that we can terminate with a pretty error message,
rather than the monstrosity shown in pulumi/pulumi#359.
2017-09-23 12:20:11 +00:00
|
|
|
}
|
|
|
|
|
2018-08-31 19:33:01 +00:00
|
|
|
func (d *defaultSink) Errorf(diag *Diag, args ...interface{}) {
|
2018-05-07 22:11:52 +00:00
|
|
|
msg := d.createMessage(Error, diag, args...)
|
2018-05-15 22:28:00 +00:00
|
|
|
if logging.V(5) {
|
|
|
|
logging.V(5).Infof("defaultSink::Error(%v)", msg[:len(msg)-1])
|
2016-11-16 00:30:10 +00:00
|
|
|
}
|
2023-03-23 23:11:27 +00:00
|
|
|
d.print(Error, msg)
|
2016-11-15 19:30:34 +00:00
|
|
|
}
|
|
|
|
|
2018-08-31 19:33:01 +00:00
|
|
|
func (d *defaultSink) Warningf(diag *Diag, args ...interface{}) {
|
2018-05-07 22:11:52 +00:00
|
|
|
msg := d.createMessage(Warning, diag, args...)
|
2018-05-15 22:28:00 +00:00
|
|
|
if logging.V(5) {
|
|
|
|
logging.V(5).Infof("defaultSink::Warning(%v)", msg[:len(msg)-1])
|
2016-11-16 00:30:10 +00:00
|
|
|
}
|
2023-03-23 23:11:27 +00:00
|
|
|
d.print(Warning, msg)
|
|
|
|
}
|
|
|
|
|
|
|
|
func (d *defaultSink) print(sev Severity, msg string) {
|
|
|
|
fmt.Fprint(d.writers[sev], msg)
|
2016-11-15 19:30:34 +00:00
|
|
|
}
|
|
|
|
|
2018-05-07 22:11:52 +00:00
|
|
|
func (d *defaultSink) Stringify(sev Severity, 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 != Info && sev != Infoerr {
|
|
|
|
// Unless it's an ordinary stdout message, prepend the message category's prefix (error/warning).
|
|
|
|
switch sev {
|
|
|
|
case Debug:
|
|
|
|
prefix.WriteString(colors.SpecDebug)
|
|
|
|
case Error:
|
|
|
|
prefix.WriteString(colors.SpecError)
|
|
|
|
case 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 Info, Infoerr:
|
|
|
|
// We'll never get here, but the linter doesn't recognize that.
|
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-02-10 01:26:49 +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)
|
2016-11-15 19:30:34 +00:00
|
|
|
|
2017-11-14 19:26:41 +00:00
|
|
|
if diag.Raw {
|
|
|
|
buffer.WriteString(diag.Message)
|
|
|
|
} else {
|
2023-02-23 21:14:41 +00:00
|
|
|
fmt.Fprintf(&buffer, diag.Message, args...)
|
2017-11-14 19:26:41 +00:00
|
|
|
}
|
2017-02-10 01:26:49 +00:00
|
|
|
|
2017-12-14 19:53:02 +00:00
|
|
|
buffer.WriteString(colors.Reset)
|
2016-11-15 19:30:34 +00:00
|
|
|
buffer.WriteRune('\n')
|
|
|
|
|
2018-05-15 23:09:15 +00:00
|
|
|
// Ensure that any sensitive data we know about is filtered out preemptively.
|
|
|
|
filtered := logging.FilterString(buffer.String())
|
|
|
|
|
2017-02-10 01:26:49 +00:00
|
|
|
// If colorization was requested, compile and execute the directives now.
|
2018-05-15 23:09:15 +00:00
|
|
|
return d.opts.Color.Colorize(prefix.String()), d.opts.Color.Colorize(filtered)
|
2016-11-15 19:30:34 +00:00
|
|
|
}
|
2023-03-23 23:11:27 +00:00
|
|
|
|
|
|
|
// syncWriter wraps an io.Writer and ensures that all writes are synchronized
|
|
|
|
// with a mutex.
|
|
|
|
type syncWriter struct {
|
|
|
|
io.Writer
|
|
|
|
|
|
|
|
mu *sync.Mutex
|
|
|
|
}
|
|
|
|
|
|
|
|
func (w *syncWriter) Write(p []byte) (int, error) {
|
|
|
|
w.mu.Lock()
|
|
|
|
defer w.mu.Unlock()
|
|
|
|
return w.Writer.Write(p)
|
|
|
|
}
|