Create and Duplicate Resource actions

[nobbs]

This PR is basically a rework of PR #954 which is coming originally from @nickymateev - as there hasn't been any real activity by him on his original PR for the last 3 years and the functionality would be nice to have, I've rebased his work and streamlined it a bit.

Functionality in general is still the same, this PR introduces two new options:

1. Create triggered by Ctrl + N on every resource browse view, which opens the default editor, puts in some explanation and waits for the user to save and close the editor. Then it will run kubectl create on the provided contents to create these resources.
2. Duplicate triggered by Shift + D on the YAML view of a resource. Behaviour is very similar, instead of showing an empty file, it will grab the YAML of the selected resource and again run kubectl create on the contents once saved on closed.

There is one key difference between the approach in #954 and this PR, in the original kubectl apply was used while this PR switched to kubectl create. Why? Well, the answer is simple, create will make sure that the user can't overwrite an existing resource simply by specifying the same name - for this the good old edit action has been around for a long time. This way, kubectl itself will act as a safeguard preventing users that simply forgot to change the name from messing up existing resources by either the create or duplicate actions.

Also, this PR fixes the way the lookup of the preferred editor from the env vars KUBE_EDITOR, K9S_EDITOR and / EDITOR works. For most non-terminal editors, e.g. VSCode, one has to additionally pass an argument to prevent it from closing immediately, i.e. KUBE_EDITOR="code --wait". This broke the lookup, as k9s was trying to find a binary with the name code --wait on the $PATH. This is now refactored to properly split any args from the binary to make sure we're really only looking for a binary name. Should hopefully also work on Windows, but I'm not able to test it myself.

Readonly flag is supported, so both actions are not enabled if read-only flag is set.

On the original PR, @derailed noted that he doesn't like running imperative commands on a cluster to create resources without keeping the manifest on disk. For this PR, I simply decided to abuse the screen dumps dir and store a copy of the provided yaml file in there. The path is shown as part of the result of the create call.

Screenshots

[nobbs]

~~Looking into fixing those failing tests - they work locally, so will need to retest on CICD.~~

Fixed the failing test. I forgot to make use of the mock lookPath implementation for testing... 🙈

[tiaguito]

Hi @nobbs Could you also edit the Readme file, in the key bindings section, and add the new actions, their keybindings, and their description?

[miquella]

@nobbs First off Alexej thank you for this update and your attention to details!

I have to say I am struggling with this a bit. I can see the usefulness while experimenting with a cluster. But as I've voiced before I am not keen on cluster cowboying. Moreover users would likely leverage helm/kustomize/... to provision their clusters. Hence the one offs could be duds.

@derailed: Not sure if it will help, but I thought it might be useful to convey my experience here:

When working against development clusters, I often come across situations where a resource is misconfigured or completely missing. I've always found myself glad when it's just a misconfiguration because I can just fix the issue with the edit feature in k9s.

However, when a resource is missing, it's much more disruptive. Switching to kubectl, I have to make sure the context and namespace are correct since I'm often jumping between multiple clusters and namespaces. The spec has to be written to a file, just in case I goof something and the initial creation fails. The edit feature in k9s doesn't have these drawbacks, as it's already in context and if I goof something, it reopens the editor with my (incorrect) spec so that I can fix it.

Breaking my flow to create a missing resource like this feels extra painful since the existing edit functionality almost does what would be needed (aside from the actual creation part).

Note: I absolutely do not advocate cowboying like this on production clusters! I only work this way when working on development clusters… 😉😅

Imho I think the create functionality is a dud. Don't think there is value starting from a blank slate. Duplicating a res may make sense but the amount of editing and corrections required could also be daunting ie users would have to plow thru managed fields + additional instance specific bits injected by the control plane ie uuid, timestamps etc...

It is a bit rough starting from scratch, I agree. Duplicating sounds nice on paper, but the "gotchas" you describe would certainly make it treacherous to use…

… I think for this feature to actually make sense would be to actually leverage the context at hand. For example if the user is in pod or cm view a pod/cm artifact skeleton with some filled in fields ie name/namespace or others based on current context.

Would this make sense?

Personally, I think this would make a ton of sense.

Just having the basics like API group, version, kind, and namespace would go a long way to helping it feel better integrated. I could see an argument for a few other fields on a kind-by-kind basis, but I would be happy with just the basics 😄

[vash]

Hi all, I've just added a plugin of mine called dup. It's a krew plugin aiming to be able to duplicate all resources (inc. customs).

I'm currently attempting to get it #2831 accepted as a plugin for K9s as well. I think it takes care of the Duplicate + Edit portions of the request here.

[KevinGimbel]

I had a very quick look at dup and it seems that the plugin added in #2831 could provide the functionality for those who need it without adding it to the core of k9s.