misleading / confusing "illegal base64 data at input byte 0" on invalid k8s secret values

[landism]

Expected Behavior

Tilt indicates what field in what object is invalid.

Current Behavior

The output looks like this:

ERROR: Traceback (most recent call last):
  /Users/matt/go/src/github.com/tilt-dev/servantes/deploy/Tiltfile:1:9: in <toplevel>
  <builtin>: in k8s_yaml
Error: illegal base64 data at input byte 0

On first glance, it looks like it's trying to read the yaml as base64 and finding a problem at the first byte, which is very confusing! And then even if one is aware of the problem described in this issue, Tilt provides no help narrowing down what part of the yaml is problematic.

When trying to create the secret directly via kubectl, the output pinpoints the problem:

Error from server (BadRequest): error when creating "secrets.yaml": Secret in version "v1" cannot be handled as a Secret: v1.Secret.Data: decode base64: illegal base64 data at input byte 0

Steps to Reproduce

Try to load any secret with a non-base64 value, e.g.:

k8s_yaml(blob('''apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  stuff: "!"'''))

tilt up

Context

tilt doctor Output

$ tilt doctor
Tilt: v0.26.3-dev, built 2022-03-28
System: darwin-arm64
---
Docker
- Host: [default]
- Server Version: 20.10.11
- API Version: 1.41
- Builder: 2
- Compose Version: v1.29.2 (build 5becea4c)
---
Kubernetes
- Env: kind
- Context: kind-kind
- Cluster Name: kind-kind
- Namespace: default
- Container Runtime: containerd
- Version: v1.21.1
- Cluster Local Registry: {Host:localhost:58059 hostFromCluster: SingleName:}```

[milas]

I've got an improvement here in #5741, so that the errors will now look something like:

Error: decoding Secret "my-secret": illegal base64 data at input byte 0

This is still missing the field path (v1.Secret.Data) as shown in the kubectl message from the issue description, so it's still kinda confusing because it implies the entire object is invalid base64 instead of just the .Data field.

I cannot figure out how/why the apiserver is able to produce this message – it's coming from the decoder there, but I can't tell what is different vs our decoder. I've tried using various different decoder factory methods and options (e.g. strict) to no avail. It's also not greppable since it's coming from a string format (e.g. fmt.Sprintf("%s: %v", field, err) type of thing)