klog 2.30.0, logr 1.2.0, zapr 1.2.0

The new releases fix logging of KObj in JSON output: klog implements the new
logr.Marshaler interface and zapr uses it instead of Stringer when logging the
ObjectRef created by KObj.

vendor/github.com/go-logr/logr/.golangci.yaml

@@ -0,0 +1,29 @@
+run:
+  timeout: 1m
+  tests: true
+
+linters:
+  disable-all: true
+  enable:
+    - asciicheck
+    - deadcode
+    - errcheck
+    - forcetypeassert
+    - gocritic
+    - gofmt
+    - goimports
+    - gosimple
+    - govet
+    - ineffassign
+    - misspell
+    - revive
+    - staticcheck
+    - structcheck
+    - typecheck
+    - unused
+    - varcheck
+
+issues:
+  exclude-use-default: false
+  max-issues-per-linter: 0
+  max-same-issues: 10

vendor/github.com/go-logr/logr/README.md

@@ -1,5 +1,7 @@
 # A minimal logging API for Go
 
+[![Go Reference](https://pkg.go.dev/badge/github.com/go-logr/logr.svg)](https://pkg.go.dev/github.com/go-logr/logr)
+
 logr offers an(other) opinion on how Go programs and libraries can do logging
 without becoming coupled to a particular logging implementation.  This is not
 an implementation of logging - it is an API.  In fact it is two APIs with two
@@ -102,14 +104,15 @@ with higher verbosity means more (and less important) logs will be generated.
 
 There are implementations for the following logging libraries:
 
-- **a function**: [funcr](https://github.com/go-logr/logr/tree/master/funcr)
+- **a function** (can bridge to non-structured libraries): [funcr](https://github.com/go-logr/logr/tree/master/funcr)
 - **github.com/google/glog**: [glogr](https://github.com/go-logr/glogr)
-- **k8s.io/klog**: [klogr](https://git.k8s.io/klog/klogr)
+- **k8s.io/klog** (for Kubernetes): [klogr](https://git.k8s.io/klog/klogr)
 - **go.uber.org/zap**: [zapr](https://github.com/go-logr/zapr)
 - **log** (the Go standard library logger): [stdr](https://github.com/go-logr/stdr)
 - **github.com/sirupsen/logrus**: [logrusr](https://github.com/bombsimon/logrusr)
 - **github.com/wojas/genericr**: [genericr](https://github.com/wojas/genericr) (makes it easy to implement your own backend)
 - **logfmt** (Heroku style [logging](https://www.brandur.org/logfmt)): [logfmtr](https://github.com/iand/logfmtr)
+- **github.com/rs/zerolog**: [zerologr](https://github.com/go-logr/zerologr)
 
 ## FAQ
 

vendor/github.com/go-logr/logr/logr.go

@@ -21,7 +21,7 @@ limitations under the License.
 // to back that API.  Packages in the Go ecosystem can depend on this package,
 // while callers can implement logging with whatever backend is appropriate.
 //
-// # Usage
+// Usage
 //
 // Logging is done using a Logger instance.  Logger is a concrete type with
 // methods, which defers the actual logging to a LogSink interface.  The main
@@ -45,7 +45,7 @@ limitations under the License.
 // LogSink implementations can choose to do things like attach additional
 // information (such as stack traces) on calls to Error().
 //
-// # Verbosity
+// Verbosity
 //
 // Often we want to log information only when the application in "verbose
 // mode".  To write log lines that are more verbose, Logger has a V() method.
@@ -62,7 +62,7 @@ limitations under the License.
 // We can write:
 //   logger.V(2).Info("an unusual thing happened")
 //
-// # Logger Names
+// Logger Names
 //
 // Logger instances can have name strings so that all messages logged through
 // that instance have additional context.  For example, you might want to add
@@ -79,7 +79,7 @@ limitations under the License.
 // joining operation (e.g. whitespace, commas, periods, slashes, brackets,
 // quotes, etc).
 //
-// # Saved Values
+// Saved Values
 //
 // Logger instances can store any number of key/value pairs, which will be
 // logged alongside all messages logged through that instance.  For example,
@@ -97,7 +97,7 @@ limitations under the License.
 //   // later on...
 //   obj.logger.Info("setting foo", "value", targetValue)
 //
-// # Best Practices
+// Best Practices
 //
 // Logger has very few hard rules, with the goal that LogSink implementations
 // might have a lot of freedom to differentiate.  There are, however, some
@@ -112,7 +112,7 @@ limitations under the License.
 // may be any Go value, but how the value is formatted is determined by the
 // LogSink implementation.
 //
-// # Key Naming Conventions
+// Key Naming Conventions
 //
 // Keys are not strictly required to conform to any specification or regex, but
 // it is recommended that they:
@@ -129,22 +129,21 @@ limitations under the License.
 // While users are generally free to use key names of their choice, it's
 // generally best to avoid using the following keys, as they're frequently used
 // by implementations:
-//
-//   * "caller": the calling information (file/line) of a particular log line.
-//   * "error": the underlying error value in the `Error` method.
-//   * "level": the log level.
-//   * "logger": the name of the associated logger.
-//   * "msg": the log message.
+//   * "caller": the calling information (file/line) of a particular log line
+//   * "error": the underlying error value in the `Error` method
+//   * "level": the log level
+//   * "logger": the name of the associated logger
+//   * "msg": the log message
 //   * "stacktrace": the stack trace associated with a particular log line or
-//                   error (often from the `Error` message).
-//   * "ts": the timestamp for a log line.
+//                   error (often from the `Error` message)
+//   * "ts": the timestamp for a log line
 //
 // Implementations are encouraged to make use of these keys to represent the
 // above concepts, when necessary (for example, in a pure-JSON output form, it
 // would be necessary to represent at least message and timestamp as ordinary
 // named values).
 //
-// # Break Glass
+// Break Glass
 //
 // Implementations may choose to give callers access to the underlying
 // logging implementation.  The recommended pattern for this is:
@@ -477,3 +476,21 @@ type CallStackHelperLogSink interface {
 	// call site information.
 	GetCallStackHelper() func()
 }
+
+// Marshaler is an optional interface that logged values may choose to
+// implement. Loggers with structured output, such as JSON, should
+// log the object return by the MarshalLog method instead of the
+// original value.
+type Marshaler interface {
+	// MarshalLog can be used to:
+	//   - ensure that structs are not logged as strings when the original
+	//     value has a String method: return a different type without a
+	//     String method
+	//   - select which fields of a complex type should get logged:
+	//     return a simpler struct with fewer fields
+	//   - log unexported fields: return a different struct
+	//     with exported fields
+	//
+	// It may return any value of any type.
+	MarshalLog() interface{}
+}