Debugging Tools in UI (e.g. filewatch)

[rwoll]

Describe the Feature You Want

Add UI bits to debug filewatches (globally and per-resource)

Current Behavior

Filewatch information is not available except for the CLI. See https://docs.tilt.dev/file_changes.html.

Why Do You Want This?

The few times I've had to debug filewatches, I found myself stumbling, especially having not used kubectl in years. The guide in https://docs.tilt.dev/file_changes.html works, but unless you know k8s CLI use, it can be a bit overwhelming!

[hyu]

Hi @rwoll, thanks for this suggestion! We've heard good feedback that people found tilt get filewatches useful, so I agree that it could be really helpful to make some of this information more readily available in the UI!

Given that there's a veritable firehose of information that could be included in the UI, and that the UI is already quite information-rich, it can be tricky to really think about what's most relevant to show, and where and when it's best to show it. So, better understanding your specific use cases would be helpful to iterate on possible designs.

So — what kinds of questions are you usually asking? e.g. "What file change triggered this specific rebuild?" or "Why isn't this particular resource building when I expect it to?"

[rwoll]

So — what kinds of questions are you usually asking? e.g. "What file change triggered this specific rebuild?" or "Why isn't this particular resource building when I expect it to?"

Both these questions are exactly what I've used the filewatches API for. (I can't think of other examples.)

I've only needed to use it a handful of times every couple of weeks, so I wouldn't expect this to be featured in the UI (or be high priority). As long as the current filewatch docs link to where it is in the UI (even if it's not super discoverable) that would be helpful. As someone who doesn't use k8s regularly, navigating the filewatches on the CLI feels awkward and cryptic. Even something as basic of "I've listed the filewatch resources, how do I get details?" Once I've figured out details, I'm staring at some YAML in a terminal which works, but isn't optimal (the resource context isn't there and other Tilt metadata about the resource is absent).

Thanks!

[nicksieger]

I think most often the relevant bit of information in a file watch is the item at the end of the .status.fileEvents array. This might be something we could expose in the UI in a way that could be referred to regularly.

Does the N file changed: ...list of files... separator strip in the log pane tend to get lost in the log noise?

Or maybe there are too many changes and the listing in the strip is elided anyway?

[rwoll]

Thanks @nicksieger! That line has been helpful, but does get buried in logs. For local/tilt dev, we turn on the most verbose logging for all our services.