Feature Request: Export Raw Kubernetes Resource YAML to File (K9s-style Screendump)

[shadow1runner]

It would be useful to have a feature similar to K9s's screendump functionality, allowing users to export the complete raw YAML definition of a selected Kubernetes resource directly to a local file.

While Sofka already supports :snapshot yaml, this appears to export the current table view rather than the full Kubernetes resource manifest.

Proposed functionality

• Export the complete YAML of the currently selected resource, as returned by the Kubernetes API.
• Save it to a local file, ideally with a configurable destination.
• Support a keyboard shortcut or command (e.g., :dump or :export yaml).
• Optionally allow exporting multiple selected resources.

Use cases

• Debugging and troubleshooting Kubernetes resources.
• Sharing resource definitions for further analysis.
• Comparing resource states over time.
• Creating backups prior to manual edits (for diffs etc.)
• Capturing manifests without switching to kubectl.

Questions

1. Is there already a way to achieve this in Sofka that I might have missed?
2. Would this functionality be a reasonable addition, potentially as an extension of the existing snapshot mechanism?

Thanks for considering!

[sueun-dev]

With v0.31.8's default keys, select an ordinary Kubernetes resource, press y, then c in the YAML view, and paste into an editor to save a file. That's a manual capture of displayed resource YAML. :snapshot yaml indeed captures table columns and rows.

If you need metadata.managedFields, press m and wait for the read to finish successfully before copying. They start hidden. The YAML view reserializes the object, so I wouldn't call it a byte-identical API backup. Helm rows show the rendered chart manifest instead.

I checked the extracted copy_doc/doc_text methods on Rust 1.90.0 with an authored document type and recording clipboard target. Search and scroll didn't remove lines, Unicode was preserved, and an empty document warned without requesting a copy. This checks the payload, not a running TUI, Kubernetes API or OS clipboard. Direct file saving and multiple-resource export would still remove those manual steps.

[nklmilojevic]

Thanks for the clear write-up, and thanks @sueun-dev for the workaround and the details on managedFields!

You read :snapshot right - it captures the table, not manifests, and today only Logs can save to a file (ctrl-s). So no, you didn't miss anything.

What I'd do:

1. ctrl-s saves the open document in the YAML, describe, diff and events views - same action and key as saving logs. It writes exactly what's on screen, so managedFields are in only if you turned them on with m. As @sueun-dev said, YAML is reserialized from the object, so it's the manifest as the API returns it, not a byte-for-byte copy.
2. A configurable destination - one save_dir option shared by log and document saves, defaulting to the temp directory like logs today.

Out of scope for now: extending :snapshot, since it's a table capture and a different job, and exporting several marked resources at once. One document per save first.

I'll create an issue for this and link it here.

[nklmilojevic]

Created #897 for this. Closing this one, follow along there :)