Open phmarek opened 10 months ago
Are you using Kapply
on the resource buffer directly?(buffer name starts with kube://
)
Kapply
is actually meant to be used with local files, so it doesn't modify the buffer after applying.
But if you're trying to apply a resource buffer, you can simply save it normally with :w
after making changes, that should both apply the resource and update the buffer contents to the latest fetched resource manifest.
There's also a <leader>r
mapping defined that can update the resource at any time, although this will discard any unsaved changes.
I hope that helps.
Ah yeah, thanks! Seems I forgot about that because the cursor position is lost.
I guess when replacing the buffer contents the lines are removed for a short time, so the cursor moves to the first line - so the context is lost.
Another reason why I didn't use :w
is that when changing eg. a BuildConfig
and using that to build an image, the metadata.generation
number gets incremented as well.
So if I'm still in the buffer after the image was built, change something and do :w
, I get the the object has been modified; please apply your changes to the latest version and try again
error again...
Yeah, <leader>r
helps here -right. I just have to remember what I did change...
Would it be a good idea to detect that and trying a merge? But there's only the current version and the user's version, no base for a 3-way-merge... Well, at least diff mode with the two contents should be possible.
I pushed a change that should fix the cursor reset issue 6b85ccc
The manifest updating on the cluster annoys me too, but I haven't been able to come up with a reliable method to detect changes so I've been managing with <leader>r
. Might have to pick between repeatedly polling the resource at a regular interval, or using something like kubectl watch
.
Opening diff mode during a conflict sounds interesting though, I'll try exploring that, thanks.
Might have to pick between repeatedly polling the resource at a regular interval, or using something like
kubectl watch
.
No, please don't cause any load - not locally and not in the cluster. If there's a way to react to some trigger, that might be fine -- though that still leaves open the problem of merging!
Opening diff mode during a conflict sounds interesting though, I'll try exploring that, thanks.
I believe that detecting that object modified
error, trying to merge some stuff automatically and showing the diff
view is the sane approach.
There's metadata.annotations[kubectl.kubernetes.io/last-applied-configuration]
, perhaps that helps for a 3-way merge?
The problem is that there's no way to parse yaml/json natively in vimscript so reading fields reliably is difficult. It can be done with external tools like jq
but I'm not sure about adding another dependency to the plugin.
Maybe we could just detect failure on apply and then do a 3 way diff with last fetched version, edited version and latest cluster version.
Hi,
first of all -- thanks a lot for this plugin!
One thing I'm always stumbling over is that when I edit some cluster resource and
Kapply
it, themetadata.resourceVersion
changes in the cluster but not in the vim buffer - so when I do further changes and try toKapply
again, I get an error likewhich means that my local changes are lost (unless I remember which lines I modified and/or write the buffer to some temp file or similar stuff).
Is there an easy way to fetch the new
resourceVersion
onKapply
and fix the buffer, or perhaps to replace the buffer contents with a new checkout, so that changes and aKapply
work immediately?Thanks a lot!