Error watching PipelineRun logs with tkn

[lbernick]

Split off from tektoncd/pipeline#5964 (reported by @bendory).

Steps to Reproduce

Create a v1beta1 PipelineRun with kubectl create. tkn logs -f displays the following error (you have to wait a bit for it to show up):

W0106 10:47:22.093684   57016 reflector.go:347] github.com/tektoncd/pipeline/pkg/client/informers/externalversions/factory.go:117: watch of *v1.PipelineRun ended with: an error on the server ("unable to decode an event from the watch stream: unable to decode watch event: no kind \"PipelineRun\" is registered for version \"tekton.dev/v1\" in scheme \"github.com/tektoncd/pipeline/pkg/client/clientset/versioned/scheme/register.go:32\"") has prevented the request from succeeding

This error is only present when using the -f flag (which watches the pipelinerun for updates).
It's not present in the PipelineRun logs themselves.
This error should have been resolved by tektoncd/pipeline#5948 but it's unclear why it was not.
Not sure yet if this is an issue with Pipelines or tkn, but this can be transferred to the CLI repo if necessary.

Additional Info

• Kubernetes version:

  Output of kubectl version:

$ kubectl version
WARNING: This version information is deprecated and will be replaced with the output from kubectl version --short.  Use --output=yaml|json to get the full version.
Client Version: version.Info{Major:"1", Minor:"24", GitVersion:"v1.24.8", GitCommit:"fdc77503e954d1ee641c0e350481f7528e8d068b", GitTreeState:"clean", BuildDate:"2022-11-09T13:38:19Z", GoVersion:"go1.18.8", Compiler:"gc", Platform:"darwin/arm64"}
Kustomize Version: v4.5.4
Server Version: version.Info{Major:"1", Minor:"24", GitVersion:"v1.24.7-gke.900", GitCommit:"e35c4457f66187eff006dda6d2c0fe12144ef2ec", GitTreeState:"clean", BuildDate:"2022-10-26T09:25:34Z", GoVersion:"go1.18.7b7", Compiler:"gc", Platform:"linux/amd64"}

• Tekton Pipeline version:

$ tkn version
Client version: 0.28.0
Chains version: v0.13.1
Pipeline version: v0.43.1

[lbernick]

I think this may have been fixed by #1838 since I'm no longer seeing this error message using the CLI built from source.